From pwg-announce-bounces@pwg.org Mon Jul 1 07:42:12 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475D511E820F for ; Mon, 1 Jul 2013 07:42: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hpZ36iSXNI5 for ; Mon, 1 Jul 2013 07:42:07 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9A411E813F for ; Mon, 1 Jul 2013 07:42:06 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 5EC70791FE; Mon, 1 Jul 2013 10:41:27 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by pwg.org (Postfix) with ESMTP id C1CF879232 for ; Mon, 1 Jul 2013 10:41:01 -0400 (EDT) Received: by mail-ie0-f179.google.com with SMTP id c10so9688738ieb.10 for ; Mon, 01 Jul 2013 07:41:00 -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=TLXcvYdUBsYRDuJSHOuk8P/34PZoTvHzFK3Pcy6nNXI=; b=Lkdm8ydK5Nj0P6op30rZc0VhwLs7l9tZSD0/KYOlLagHBk5g/dwsJL1kcILv07X34g /Ox8shs9OvVa8YsWDEF5xuIAV6w3DAL0cMSr1O5Z6L049vZFsN+ST/Z2qsWWpvbYoLi7 Zb32S2/u6ml2kPB4vLVhwZwz9OadY5meE+iKQEfYqLez3x/eAFGRSMvpZh8mVqgOFIz/ DKo/lT+AudNBzBO4VvyiwcBwoOGW+5AXnOQMxYPkL6vj6g6xQ9Y0dJ6gm6GZTz+s0cl6 F63/OOozl+66tHcsYqFGLxqZfBrLX44Cf6RUgrUac184yCQhhen3SAyCxncyj9BU2F1+ un+Q== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr10911974igt.54.1372689653978; Mon, 01 Jul 2013 07:40:53 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Mon, 1 Jul 2013 07:40:53 -0700 (PDT) Date: Mon, 1 Jul 2013 10:40:53 -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] IPP FaxOut quorum achieved in PWG Last Call 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="===============0255138680==" 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: 5EC70791FE.ADC18 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============0255138680== Content-Type: multipart/alternative; boundary=047d7bd75244365b6304e074376a --047d7bd75244365b6304e074376a Content-Type: text/plain; charset=ISO-8859-1 Hi, Many thanks to all of you who participated in the PWG Last Call of the IPP FaxOut spec - completed last Friday 28 June. We achieved quorum w/ 12 responses (7 w/ comments). The editor (Mike Sweet) and the IPP WG will now consider and respond to the comments. Cheers, - Ira (co-chair of IPP WG) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --047d7bd75244365b6304e074376a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Many t= hanks to all of you who participated in the PWG
Last Call of the I= PP FaxOut spec - completed last Friday
28 June.

We ac= hieved quorum w/ 12 responses (7 w/ comments).

The editor (Mike Sweet) and the IPP WG will now consider
and r= espond to the comments.

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


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Op= en 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 &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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --047d7bd75244365b6304e074376a-- --===============0255138680== 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 --===============0255138680==-- From ipp-bounces@pwg.org Wed Jul 3 12:14:50 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6893B21F9D04 for ; Wed, 3 Jul 2013 12:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_00=-2.599] 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 fGlNdyRHpEpp for ; Wed, 3 Jul 2013 12:14:44 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA2D21F926E for ; Wed, 3 Jul 2013 12:14:44 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 46FA6791EE; Wed, 3 Jul 2013 15:13:54 -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 20391791D2 for ; Wed, 3 Jul 2013 15:13:29 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPD003YJK29BEG1@mail-out.apple.com> for ipp@pwg.org; Wed, 03 Jul 2013 12:13:29 -0700 (PDT) X-AuditID: 1180715a-b7f506d000007d18-5b-51d477d77536 Received: from [17.153.37.78] (Unknown_Domain [17.153.37.78]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 48.15.32024.8D774D15; Wed, 03 Jul 2013 12:13:29 -0700 (PDT) From: Michael Sweet Date: Wed, 03 Jul 2013 15:13:26 -0400 To: ipp@pwg.org Message-id: <1DC9FCEE-BA44-44B6-84D1-B3A38FC362C7@apple.com> X-Mailer: Apple Mail (2.1783) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUiOFPVT/dm+ZVAgwlfRS2O7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlfF902rmgl72igXrb7A2MH5i7WLk5JAQMJH4 +XESG4QtJnHh3nogm4tDSKCbSeLsvX6wIjYBNYnfk/rAbGYBLYkb/14yQdjaEssWvmYGsVkE VCSunv0LViMsYCTRMvkRO4gtIsAvMfEiSC8HB6+AjcTdoxEQpp7E6aMBEGtlJSa1PWObwMgz C8mCWUgWzELoWMDIvIpRoCg1J7HSTC+xoCAnVS85P3cTIyhIGgqjdjA2LLc6xCjAwajEwyth dSVQiDWxrLgy9xCjBAezkgjvwXigEG9KYmVValF+fFFpTmrxIUZpDhYlcd4U6UuBQgLpiSWp 2ampBalFMFkmDk6pBka5qCZdhRg7t33f85hv1W8T7J+W08iQfjTbfRX7L89TZ+KzPmwJ7/XV e9hwMcKecfb7TzK7ZjZXGM+QuZ07bVrahsluYWfsp/gd/OJrtDv+6dw/MzlzWDgfxPfe2Df/ 21WZl38tXmWEdqc+SN4lbSVkt/65ydwjnxdOs3M/LyxwJu7gmY4JvduUWIozEg21mIuKEwEx RhokDgIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] output-bin value for roll-fed printers... 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: 46FA6791EE.A9C4D X-pwg-MailScanner-From: ipp-bounces@pwg.org All, PWG 5100.2 is missing a keyword value for roll-fed printers. While technically most roll-fed printers produce face-up output (and thus could use the value 'face-up'), this also has the unfortunate connotation that the stacking order is reversed since most printers producing face-up output *do* stack the output in reverse order. The JPS3 printer-output-tray attribute and corresponding Printer MIB prtOutput properties do provide the correct stacking order, direction (up/down), and type of each output bin/tray, however printer-output-tray is still not widely supported and would seem to be overkill for just describing that a printer's output is not stacked. Does anyone object to adding a new value of 'roll' for the "output-bin" attribute? _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Thu Jul 4 09:03:04 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9440611E8135 for ; Thu, 4 Jul 2013 09:03:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elvl21JAS0dp for ; Thu, 4 Jul 2013 09:02:59 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4521F21F9FE6 for ; Thu, 4 Jul 2013 09:02:59 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id D948A791E9; Thu, 4 Jul 2013 12:02:31 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by pwg.org (Postfix) with ESMTP id 8DFF0791E3 for ; Thu, 4 Jul 2013 12:02:09 -0400 (EDT) Received: by mail-ie0-f179.google.com with SMTP id c10so3464746ieb.38 for ; Thu, 04 Jul 2013 09:02:09 -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=m0ZYmzKWuWDbFSePSp4LL8avZqtZBOsn5q73f0SyeJM=; b=lMca6w++41TfEaujHC6XL7e6Nc0oqf1ugcwyuu3T0izeBUEwMgP79+cGdIglkG3jf1 FpgtOVgCzddkI4g7ZEYPm4lsxFgbPGsXev1plukUhM4xkOJK846G6zDA1+fy/X+KqTr9 DFFtxVDb48nyeIxPaLiTwJCA3ssNXDADJer/PtgbjBuSUv5VlrSH9trnjqBMSq+5oah8 C2O2E2iD3ZFj6F5KD6cksLJUhEjRSm31e4u0uBIaLCiqMLXHYsa8QLq3FXspoY4eEANg MWX8F5eysaX7Kw5A335lBvoJlx3Tr2zmSuQkh5n72UcZi4Ol8iJIUGYjD/7fuZ3PTjTJ ivtw== MIME-Version: 1.0 X-Received: by 10.50.67.111 with SMTP id m15mr3000822igt.54.1372953729066; Thu, 04 Jul 2013 09:02:09 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Thu, 4 Jul 2013 09:02:08 -0700 (PDT) In-Reply-To: <1DC9FCEE-BA44-44B6-84D1-B3A38FC362C7@apple.com> References: <1DC9FCEE-BA44-44B6-84D1-B3A38FC362C7@apple.com> Date: Thu, 4 Jul 2013 12:02:08 -0400 Message-ID: Subject: Re: [IPP] output-bin value for roll-fed printers... From: Ira McDonald To: Michael Sweet 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="===============1809353646==" 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: D948A791E9.A9595 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1809353646== Content-Type: multipart/alternative; boundary=047d7bd75244506ee704e0b1b364 --047d7bd75244506ee704e0b1b364 Content-Type: text/plain; charset=ISO-8859-1 Hi Mike, I'm in favor of adding 'roll' to the "output-bin" attribute. Appropriate technology (don't use a hammer to drive a tack). Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Jul 3, 2013 at 3:13 PM, Michael Sweet wrote: > All, > > PWG 5100.2 is missing a keyword value for roll-fed printers. While > technically most roll-fed printers produce face-up output (and thus could > use the value 'face-up'), this also has the unfortunate connotation that > the stacking order is reversed since most printers producing face-up output > *do* stack the output in reverse order. > > The JPS3 printer-output-tray attribute and corresponding Printer MIB > prtOutput properties do provide the correct stacking order, direction > (up/down), and type of each output bin/tray, however printer-output-tray is > still not widely supported and would seem to be overkill for just > describing that a printer's output is not stacked. > > Does anyone object to adding a new value of 'roll' for the "output-bin" > attribute? > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --047d7bd75244506ee704e0b1b364 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mike,

I'm in favor= of adding 'roll' to the "output-bin" attribute.

<= /div>Appropriate technology (don't use a hammer to drive a tack).
Cheers,
- Ira


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



On Wed, Jul 3, 2013 at 3:13 PM, Michael = Sweet <msweet@apple.com> wrote:
All,

PWG 5100.2 is missing a keyword value for roll-fed printers. While technica= lly most roll-fed printers produce face-up output (and thus could use the v= alue 'face-up'), this also has the unfortunate connotation that the= stacking order is reversed since most printers producing face-up output *d= o* stack the output in reverse order.

The JPS3 printer-output-tray attribute and corresponding Printer MIB prtOut= put properties do provide the correct stacking order, direction (up/down), = and type of each output bin/tray, however printer-output-tray is still not = widely supported and would seem to be overkill for just describing that a p= rinter's output is not stacked.

Does anyone object to adding a new value of 'roll' for the "ou= tput-bin" attribute?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


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

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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --047d7bd75244506ee704e0b1b364-- --===============1809353646== 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 --===============1809353646==-- From ipp-bounces@pwg.org Fri Jul 5 07:32:06 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09311E80F4 for ; Fri, 5 Jul 2013 07:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.205 X-Spam-Level: X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=-2.607, 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 iNBnOjgkhbje for ; Fri, 5 Jul 2013 07:32:00 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5111E812B for ; Fri, 5 Jul 2013 07:32:00 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 9CC0D791F2; Fri, 5 Jul 2013 10:31:17 -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 84E0B791EE for ; Fri, 5 Jul 2013 10:30:53 -0400 (EDT) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPG0035SWBAA7B1@mail-out.apple.com> for ipp@pwg.org; Fri, 05 Jul 2013 07:30:52 -0700 (PDT) X-AuditID: 11807143-b7f856d000000818-10-51d6d89b6b4c Received: from [17.153.53.134] (Unknown_Domain [17.153.53.134]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 19.DD.02072.C98D6D15; Fri, 05 Jul 2013 07:30:52 -0700 (PDT) From: Michael Sweet Date: Fri, 05 Jul 2013 10:30:51 -0400 To: "ipp@pwg.org" Message-id: <4479F799-1A68-4262-AB5E-5FEF873E4D43@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiONO0TXfOjWuBBmd6tC2O7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlbHo0V72gr/CFbeumjYw7hDqYuTkkBAwkZhz 4SczhC0mceHeerYuRi4OIYFeJolrh56CJdgE1CR+T+pjBbGZBRIkPm2dzwRiswioSMz9vRHM FhZQl9jwaCMjiC0iIC+xtm0qWJxXwEZi5Zf/zBC2nsTSf3OAajiAlslK7PydNIGRexaSqbOQ VEHEtSWWLXzNPAuog1lAR2LyQqiwvMT2t3OYYUo+nj/CtICRbRWjQFFqTmKlkV5iQUFOql5y fu4mRlBQNRQ672A8tszqEKMAB6MSDy/H+WuBQqyJZcWVuYcYJTiYlUR47ROAQrwpiZVVqUX5 8UWlOanFhxilOViUxHmn+AClBNITS1KzU1MLUotgskwcnFINjCrvvsjsVNAuX6IZIxA+mzFR KIT5QsAS6RVP06c69e98yPvFY/I0VbnC6X+Xhwso//2rl25nq3yVfaP0+91zL96I3JsSvrRh 08O7Sw5/kHP/cv2Nk9/aiWuE7xY/+aqwwon5/r6iXJNXdhK37ssduhf9Vjnw1p3nDxtNp795 /lVUX7WCpet7u6USS3FGoqEWc1FxIgAkh1inJgIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Updated draft of IPPSIX posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0518730412==" 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: 9CC0D791F2.A889D X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0518730412== Content-type: multipart/alternative; boundary="Boundary_(ID_vx5TWLObm+lnDJgo6tzYRA)" --Boundary_(ID_vx5TWLObm+lnDJgo6tzYRA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted an updated draft of the IPP Shared Infrastructure Extensions (IPPSIX) to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705-rev.pdf Enjoy! _________________________________________________________ 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_vx5TWLObm+lnDJgo6tzYRA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I have posted an updated draft of the IPP Shared Infrastructure Extensions (IPPSIX) to:


Enjoy!

_________________________________________________________
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_vx5TWLObm+lnDJgo6tzYRA)-- --===============0518730412== 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 --===============0518730412==-- From ipp-bounces@pwg.org Sun Jul 7 09:40:10 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5B511E80A2 for ; Sun, 7 Jul 2013 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRYGEwOwh-f6 for ; Sun, 7 Jul 2013 09:40:05 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1021F9F4F for ; Sun, 7 Jul 2013 09:40:05 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 15691791A7; Sun, 7 Jul 2013 12:39:31 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by pwg.org (Postfix) with ESMTP id 19F8A791A6 for ; Sun, 7 Jul 2013 12:39:08 -0400 (EDT) Received: by mail-ie0-f172.google.com with SMTP id 16so8386157iea.31 for ; Sun, 07 Jul 2013 09:39:08 -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=EJihFM2rBsbkTNJObCEKeaf7lzAmm+uZaa9oyHc0sNI=; b=n8QdktXvfKFVsrpQjXjg6IbIbQxIrSPoZjYg2BAIdhe/zvXO9x6RYwHaNMPwCGI+Mz 2IBlPSlV2qB6o89tFF4+bfuFzn3eTXcSDnFhwEeV/zfSkFcb4QtJm065GB7LGgcPzN9O 7DKI8qqFvKJKii1CpWqbEkwfkl8KAfsw61158btxA2hUTpyocjNL/4eO1Zpof1d+x566 PjZn0SBUc6DbkvBNhTMXkkG/tm47SH7RfchYMEqxx31A0OIAH12N4Y5wD/6cpcHQVv8E wC87y9U8ehfwWhZNs9T42RDdnnXmt5+MG2JMp8bDcIjS71m855Vk8sdTzSCKeONLJ61c i4hw== MIME-Version: 1.0 X-Received: by 10.42.190.74 with SMTP id dh10mr6278074icb.35.1373215148380; Sun, 07 Jul 2013 09:39:08 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Sun, 7 Jul 2013 09:39:08 -0700 (PDT) Date: Sun, 7 Jul 2013 12:39:08 -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 8 July 2013 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="===============0397672285==" 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: 15691791A7.A955F X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0397672285== Content-Type: multipart/alternative; boundary=20cf303dda621e9f0104e0ee9129 --20cf303dda621e9f0104e0ee9129 Content-Type: text/plain; charset=ISO-8859-1 Hi, Our next IPP WG call is this week Monday 8 July 12-2pm US Pacific / 3-5pm US Eastern Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) ------------------------------------------------------- Meeting information ------------------------------------------------------- Date: Every Monday, from Monday, July 9, 2012 to no end date Time: 12:00 pm, Pacific Daylight Time (San Francisco) Meeting Number: 624 587 312 Meeting Password: pwg123 ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://appleinc.webex.com/appleinc/j.php?ED=204995427&UID=504472682&PW=NNzM5MmRlMzBl&RT=MiM0 ------------------------------------------------------- Agenda: (1) PWG IP Policy and Minute Taker - Mike (2) Approve IPP minutes from previous meeting - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130624.pdf (3) Status of IPP Transaction-based Printing Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130624-rev.pdf - Apple prototype report posted (4) Status of IPP Fax Out (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130501.pdf - PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments (5) Status of IPP Implementor's Guide v2.0 (Smith) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-bestp10-20130513-rev.pdf (6) Review of IPP Shared Infrastructure Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705-rev.pdf - model issues from Cloud WG? (7) Next steps - IPP WG telecon on Monday 22 July - IPP WG at PWG F2F on Tuesday 6 August - IPP WG at PWG F2F on Thursday 8 August 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --20cf303dda621e9f0104e0ee9129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Our next IPP WG ca= ll is this week Monday 8 July 12-2pm US Pacific / 3-5pm US Eastern

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

Attendee A= ccess Code: *******#
Attendee ID Code: # (empty)

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

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

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

(3) Status of IPP Transaction-based Printing Ex= tensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd= -ipptrans10-20130624-rev.pdf
- Apple prototype report posted

(4) Status of IPP Fax Out (Mike)
=
- PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments=

(5) Status of IPP Implementor's Guide v2.= 0 (Smith)
(6) Review of IPP Shared Infrastruct= ure Extensions (Mike)
- model issues from Cloud WG?

(7) Next steps- IPP WG telecon on Monday 22 July
= - IPP WG at PWG F2F on Tuesday 6 August
- IPP WG at PWG F2F on Thursday 8 August

Cheers,
- Ira


Ira McDonald (Musi= cian / 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 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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --20cf303dda621e9f0104e0ee9129-- --===============0397672285== 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 --===============0397672285==-- From ipp-bounces@pwg.org Mon Jul 8 07:47:42 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9321F9CFF for ; Mon, 8 Jul 2013 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.144 X-Spam-Level: X-Spam-Status: No, score=-5.144 tagged_above=-999 required=5 tests=[AWL=-2.546, 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 bNja3BygC3kK for ; Mon, 8 Jul 2013 07:47:36 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8F5721F9CF6 for ; Mon, 8 Jul 2013 07:47:34 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 98C75791D1; Mon, 8 Jul 2013 10:46:50 -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 B95EA791AA for ; Mon, 8 Jul 2013 10:46:26 -0400 (EDT) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPM000OFH19KVF0@mail-out.apple.com> for ipp@pwg.org; Mon, 08 Jul 2013 07:46:25 -0700 (PDT) X-AuditID: 11807143-b7f856d000000818-eb-51dad0c0172c Received: from [17.153.34.184] (Unknown_Domain [17.153.34.184]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 25.A6.02072.1C0DAD15; Mon, 08 Jul 2013 07:46:25 -0700 (PDT) From: Michael Sweet Date: Mon, 08 Jul 2013 10:46:28 -0400 To: "ipp@pwg.org" Message-id: <29915C20-3C1C-4DE9-A600-06085A4A1C4A@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiOFNph+7BC7cCDWbtN7Q4tu8li8WRb7EO TB5bT/5g85i3eDpTAFMUl01Kak5mWWqRvl0CV8avFf+ZCxZIVJyc8J25gfGpaBcjJ4eEgInE xy/P2CFsMYkL99azdTFycQgJ9DJJNBybyQiSYBNQk/g9qY8VxGYWSJDovnANzGYRUJGY9eIV C4gtLBAoceXELCYQW0RAXmJt21Qwm1fARmLfjDnMELaexNJ/c4BmcgAtk5XY+TtpAiP3LCRT ZyGpgohrSyxb+Jp5FlAHs4COxOSFaMIQ9sfzR5gWMLKtYhQoSs1JrDTSSywoyEnVS87P3cQI CquGQucdjMeWWR1iFOBgVOLhLTh7M1CINbGsuDL3EKMEB7OSCO+mY7cChXhTEiurUovy44tK c1KLDzFKc7AoifOedAdKCaQnlqRmp6YWpBbBZJk4OKUaGE+zJiwrkmEK9/uavuKA6lX+yRza oYdWTMtsL4t4+G1KV6rBMlnh0MkrthgHvDZy0dteJmHUu9O8QSVmF0fD0cWd5/Ysrmcxan+Y HrV4YflBDUu+tcpbzBvcF7DferPrMEtjuM++kEVOP7pFfdT0P3lYHC+OU+9nmL/w/R2d5s8P rwfce3x+khJLcUaioRZzUXEiAMbwlWgnAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Updated stable draft of IPP Transaction-Based Printing Extensions posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598887333==" 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: 98C75791D1.A92E1 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1598887333== Content-type: multipart/alternative; boundary="Boundary_(ID_dvyOIaeF986ELhWhD0iJew)" --Boundary_(ID_dvyOIaeF986ELhWhD0iJew) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted an updated stable draft of the IPP Transaction-Based Printing Extensions to: ftp://ftp.pwg.org/pub/pwg/ipp/wd-ipptrans10-20130708.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd-ipptrans10-20130708.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd-ipptrans10-20130708-rev.pdf For brief review at today's conference call, and if there are no objections I'll post a PWG Last Call of this version of the document. _________________________________________________________ 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_dvyOIaeF986ELhWhD0iJew) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable All,

I= have posted an updated stable draft of the IPP Transaction-Based Printing = Extensions to:


For brief review at today's = conference call, and if there are no objections I'll post a PWG Last Call o= f this version of the document.

____________= _____________________________________________
Michael Sweet, Senior Prin= ting 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_dvyOIaeF986ELhWhD0iJew)-- --===============1598887333== 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 --===============1598887333==-- From ipp-bounces@pwg.org Mon Jul 8 09:08:13 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EF221F9CB9 for ; Mon, 8 Jul 2013 09:08:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nme3GIKBWggX for ; Mon, 8 Jul 2013 09:08:08 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1384421F9CE8 for ; Mon, 8 Jul 2013 09:08:05 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 5227D791DC; Mon, 8 Jul 2013 12:07:22 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by pwg.org (Postfix) with ESMTP id DD27C791DB for ; Mon, 8 Jul 2013 12:06:58 -0400 (EDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id EFEAB25563; Mon, 8 Jul 2013 16:06:57 +0000 (UTC) Received: from G4W6301.americas.hpqcorp.net (16.210.26.226) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 8 Jul 2013 16:06:20 +0000 Received: from G4W3295.americas.hpqcorp.net ([169.254.3.144]) by G4W6301.americas.hpqcorp.net ([16.210.26.226]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 16:06:20 +0000 From: "Kennedy, Smith (Wireless Architect)" To: Ira McDonald Subject: Re: [IPP] IPP Agenda - 3-5pm EDT 8 July 2013 Thread-Topic: [IPP] IPP Agenda - 3-5pm EDT 8 July 2013 Thread-Index: AQHOezXyGhzJNgC9H0+SWBmxrCLc8Jla88YA Date: Mon, 8 Jul 2013 16:06:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.26] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "ipp@pwg.org" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026242185==" 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: 5227D791DC.A9CA8 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1026242185== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_745E798D-8508-4EE4-901B-EE95F9EF2847"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_745E798D-8508-4EE4-901B-EE95F9EF2847 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6E1EB5A-EF53-4C22-B328-7F87197DB969" --Apple-Mail=_C6E1EB5A-EF53-4C22-B328-7F87197DB969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Greetings, I won't be able to attend today because of a 2-day all day commitment. The= status of the IPP Implementor's Guide v2.0 is that I haven't published an = update, but will have one for the next conference call. Smith /** Smith Kennedy Hewlett-Packard Co. smith.kennedy@hp.com */ On 2013-07-07, at 10:39 AM, Ira McDonald wrote: > Hi, >=20 > Our next IPP WG call is this week Monday 8 July 12-2pm US Pacific / 3-5pm= US Eastern >=20 > Call-in toll-free number (US/Canada): 1-866-469-3239 > Call-in toll number (US/Canada): 1-650-429-3300 (Primary) > Call-in toll number (US/Canada): 1-408-856-9570 (Backup) >=20 > Attendee Access Code: *******# > Attendee ID Code: # (empty) >=20 > ------------------------------------------------------- > Meeting information > ------------------------------------------------------- > Date: Every Monday, from Monday, July 9, 2012 to no end date > Time: 12:00 pm, Pacific Daylight Time (San Francisco) > Meeting Number: 624 587 312 > Meeting Password: pwg123 > ------------------------------------------------------- > To start or join the online meeting > ------------------------------------------------------- > Go to https://appleinc.webex.com/appleinc/j.php?ED=3D204995427&UID=3D5044= 72682&PW=3DNNzM5MmRlMzBl&RT=3DMiM0 > ------------------------------------------------------- >=20 > Agenda: > (1) PWG IP Policy and Minute Taker > - Mike >=20 > (2) Approve IPP minutes from previous meeting > - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130624.pdf >=20 > (3) Status of IPP Transaction-based Printing Extensions (Mike) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130624-rev.pdf > - Apple prototype report posted >=20 > (4) Status of IPP Fax Out (Mike) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130501.pdf > - PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments >=20 > (5) Status of IPP Implementor's Guide v2.0 (Smith) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-bestp10-20130513-rev.pdf >=20 > (6) Review of IPP Shared Infrastructure Extensions (Mike) > - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705-rev.pdf > - model issues from Cloud WG? >=20 > (7) Next steps > - IPP WG telecon on Monday 22 July > - IPP WG at PWG F2F on Tuesday 6 August > - IPP WG at PWG F2F on Thursday 8 August >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=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 --Apple-Mail=_C6E1EB5A-EF53-4C22-B328-7F87197DB969 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Greetings,

I won't be able to attend today because of a 2-day all day commitmen= t.  The status of the IPP Implementor's Guide v2.0 is that I have= n't published an update, but will have one for the next conference call.

Smith

/**=
    Smith Kennedy
    Hewlett-Packard = Co.
    smith.ken= nedy@hp.com
*/

On 2013-07-07, at 10:39 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

Our next IPP WG call is th= is week Monday 8 July 12-2pm US Pacific / 3-5pm US Eastern

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

Attendee A= ccess Code: *******#
Attendee ID Code: # (empty)

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

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

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

(3) Status of IPP Transaction-based Printing Ex= tensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd= -ipptrans10-20130624-rev.pdf
- Apple prototype report posted

(4) Status of IPP Fax Out (Mike)
=
- PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments=

(5) Status of IPP Implementor's Guide v2.0 (S= mith)
(6) Review of IPP Shared Infrastruct= ure Extensions (Mike)
- model issues from Cloud WG?

(7) Next steps- IPP WG telecon on Monday 22 July
= - IPP WG at PWG F2F on Tuesday 6 August
- IPP WG at PWG F2F on Thursday 8 August

Cheers,
- Ira


Ira McDonald (Musi= cian / 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 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  579 Park Place  Saline, MI  48176  734-944-0094=
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434=

<= /div>

--=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

= --Apple-Mail=_C6E1EB5A-EF53-4C22-B328-7F87197DB969-- --Apple-Mail=_745E798D-8508-4EE4-901B-EE95F9EF2847 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIH2zCCB9cwgga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZI hvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMB4XDTEyMTEyNjAw MDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xldHQtUGFj a2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVt cGxveWVlczEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5u ZWR5MSMwIQYJKoZIhvcNAQkBFhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmoHmmwCMk0tCSI1w6tYppe JX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNNlmHy sW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTT tqMFk7JkrL1QH8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzm clRKpoDRKFT35bHptUCD0VR7IY749Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzO sQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU8Al3e/iq362nUqJm rFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWg MFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24u Y29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0Q1JMLmNy bDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQU 2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcG CCsGAQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsG AQUFBzACpIHnMIHkMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQt UGFja2FyZCBDb21wYW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhF AQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21w YW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3Jy ZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZp Y2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRo IEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFi LiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMC AgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEF BQADggEBAImyDkwpuUnbTsboOwpQAPQ4M1jbZkfWS/mLo6oj6XOWApq9IQ1j kwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnITaq9lFeagCZiq tFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVS kJN11A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+4 6gy6oM9LHtINt8Fclro/45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0W rlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xufBjNLp57JgbuFIg4xggTeMIIE 2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI /6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcwODE2MDYyN1owIwYJKoZIhvcNAQkE MRYEFJEaYrdXdAiDo2ocMb2GhPM6mxn2MIIBHwYJKwYBBAGCNxAEMYIBEDCC AQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQg Q29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9u IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI/6Xyi7Fl MIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAe BgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMs Q2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex MTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgRzICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEANc5M pD+14zGCyuYbGtm3Qw3X3sslN51UuA1jqxg3rcG13654hPJr2jJKZ7rD+O3G GZNn4nNUdegtKq4QRGtY5IJHkFnSAK5WGMYO1Viv/zdS5+tfQhXjvMBEq/Qt IlpdxSP7+nxWjQYID3iOrszxLA8B2AWrZ1qGnt7o3MQzrhsb54+/Zdeu+gcV oyH3eusmhMa+mab4hY5D9Wjg0jGcXOKlAytU7VTEJVybL71W//2MA3f+7h4i Oy9MdnnZ1P+vVByZvGfY3EVMAZ7VLGS58w+gKPec+6w/8VG+4iTNfWIJUJuQ gsEjQbtnwCkeW7OFr6XM53iuzU1kD12/WzICYAAAAAAAAA== --Apple-Mail=_745E798D-8508-4EE4-901B-EE95F9EF2847-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============1026242185== 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 --===============1026242185==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Mon Jul 8 10:38:49 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999C521F9BFB for ; Mon, 8 Jul 2013 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=-2.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD5MQk4MT6GA for ; Mon, 8 Jul 2013 10:38:44 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB7E21F9BAE for ; Mon, 8 Jul 2013 10:38:36 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3AD0B791E6; Mon, 8 Jul 2013 13:37:58 -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 CF0E5791D6 for ; Mon, 8 Jul 2013 13:37:33 -0400 (EDT) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPM00IBWOXKGI00@mail-out.apple.com> for ipp@pwg.org; Mon, 08 Jul 2013 10:37:33 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-c2-51daf8dbaaaa Received: from [17.153.54.128] (Unknown_Domain [17.153.54.128]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id AA.CB.01734.CD8FAD15; Mon, 08 Jul 2013 10:37:32 -0700 (PDT) Subject: Re: [IPP] IPP Agenda - 3-5pm EDT 8 July 2013 From: Michael Sweet In-reply-to: Date: Mon, 08 Jul 2013 13:37:36 -0400 Message-id: References: To: "Kennedy, Smith (Wireless Architect)" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUiONOsQffOj1uBBg9W6Fm8frWU3eLYvpcs Fke+xVq86trF7MDisfXkDzaPnbPusnvs2raTyWPe4ulMASxRXDYpqTmZZalF+nYJXBkXj/az FuyfwFjRvOs4awPjifouRk4OCQETiWl7b7JB2GISF+6tB7K5OIQEepkktq68ygiSEBYwlZj3 cCoTiM0roCex9N8csDizQILE4hX3WEBsNgE1id+T+lhBbE4BK4lvr3aC2SwCKhINxzazQtR7 Skze8hlqjo3E3wP/2UFsIYE6ifufN4HNFBFwkHi+5BPQTA6gg2Qldv5OmsDINwvJ5llINkPY 2hLLFr5mhrD1JF42vWPHFNeVuLhuEuMCRrZVjAJFqTmJlSZ6iQUFOal6yfm5mxhBodxQGL6D 8d8yq0OMAhyMSjy8My7eChRiTSwrrsw9xCjBwawkwrvpGFCINyWxsiq1KD++qDQntfgQozQH i5I47yl3oJRAemJJanZqakFqEUyWiYNTqoHxWGtw0tXa/xkfLs0+pFvn1cvS7/rN9nXXe/0m be7rSX9fO0gpSauk98z9rbvdZPnZ+ZHP94gcE/vW5NnbumrhOkvm3ZUNj/4JBKdsXvPJL0xx +8voAzsaC2TP1Lf+fN+/LsS+6irX8vy07nkR/65VrZ9ufSVn4lLRp/kLOJp9VzvuOq5R2t+n xFKckWioxVxUnAgAjmdxXmECAAA= 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="===============1232955456==" 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: 3AD0B791E6.A96EC X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1232955456== Content-type: multipart/alternative; boundary="Boundary_(ID_K1abrCBwjKPB2cM0nRVrXQ)" --Boundary_(ID_K1abrCBwjKPB2cM0nRVrXQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Smith, Thanks! On 2013-07-08, at 12:06 PM, "Kennedy, Smith (Wireless Architect)" wrote: > Greetings, > > I won't be able to attend today because of a 2-day all day commitment. The status of the IPP Implementor's Guide v2.0 is that I haven't published an update, but will have one for the next conference call. > > Smith > > /** > Smith Kennedy > Hewlett-Packard Co. > smith.kennedy@hp.com > */ > > On 2013-07-07, at 10:39 AM, Ira McDonald wrote: > >> Hi, >> >> Our next IPP WG call is this week Monday 8 July 12-2pm US Pacific / 3-5pm US Eastern >> >> Call-in toll-free number (US/Canada): 1-866-469-3239 >> Call-in toll number (US/Canada): 1-650-429-3300 (Primary) >> Call-in toll number (US/Canada): 1-408-856-9570 (Backup) >> >> Attendee Access Code: *******# >> Attendee ID Code: # (empty) >> >> ------------------------------------------------------- >> Meeting information >> ------------------------------------------------------- >> Date: Every Monday, from Monday, July 9, 2012 to no end date >> Time: 12:00 pm, Pacific Daylight Time (San Francisco) >> Meeting Number: 624 587 312 >> Meeting Password: pwg123 >> ------------------------------------------------------- >> To start or join the online meeting >> ------------------------------------------------------- >> Go to https://appleinc.webex.com/appleinc/j.php?ED=204995427&UID=504472682&PW=NNzM5MmRlMzBl&RT=MiM0 >> ------------------------------------------------------- >> >> Agenda: >> (1) PWG IP Policy and Minute Taker >> - Mike >> >> (2) Approve IPP minutes from previous meeting >> - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130624.pdf >> >> (3) Status of IPP Transaction-based Printing Extensions (Mike) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130624-rev.pdf >> - Apple prototype report posted >> >> (4) Status of IPP Fax Out (Mike) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130501.pdf >> - PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments >> >> (5) Status of IPP Implementor's Guide v2.0 (Smith) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-bestp10-20130513-rev.pdf >> >> (6) Review of IPP Shared Infrastructure Extensions (Mike) >> - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705-rev.pdf >> - model issues from Cloud WG? >> >> (7) Next steps >> - IPP WG telecon on Monday 22 July >> - IPP WG at PWG F2F on Tuesday 6 August >> - IPP WG at PWG F2F on Thursday 8 August >> >> 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 >> >> >> -- >> 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 > > _______________________________________________ > 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_K1abrCBwjKPB2cM0nRVrXQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Smith,

Thanks!


On 2013-07-08, at 12:06 P= M, "Kennedy, Smith (Wireless Architect)" <smith.kennedy@hp.com> wrote:

Gr= eetings,

I won't be able to attend today because of a 2-= day all day commitment.  The status of the IPP Implementor's Guid= e v2.0 is that I haven't published an update, but will have one for the nex= t conference call.

Smith

/**
    H= ewlett-Packard Co.
    <= a href=3D"mailto:smith.kennedy@hp.com">smith.kennedy@hp.com
*/

On 2013-07-07, at 10:39 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

Our next IPP WG call is th= is week Monday 8 July 12-2pm US Pacific / 3-5pm US Eastern

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

Attendee A= ccess Code: *******#
Attendee ID Code: # (empty)

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

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

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

(3) Status of IPP Transaction-based Printing Ex= tensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd= -ipptrans10-20130624-rev.pdf
- Apple prototype report posted

(4) Status of IPP Fax Out (Mike)
=
- PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments=

(5) Status of IPP Implementor's Guide v2.0 (S= mith)
(6) Review of IPP Shared Infrastruct= ure Extensions (Mike)
- model issues from Cloud WG?

(7) Next steps- IPP WG telecon on Monday 22 July
= - IPP WG at PWG F2F on Tuesday 6 August
- IPP WG at PWG F2F on Thursday 8 August

Cheers,
- Ira


Ira McDonald (Musi= cian / 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 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  579 Park Place  Saline, MI  48176  734-944-0094=
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434=

<= /div>

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

___________________________________________= ____
ipp mailing list
ipp@pwg.org<= br>https://www.pwg.org/mailman/listinfo/ipp

____________= _____________________________________________
Michael Sweet, Senior Prin= ting 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_K1abrCBwjKPB2cM0nRVrXQ)-- --===============1232955456== 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 --===============1232955456==-- From ipp-bounces@pwg.org Mon Jul 8 14:03:59 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B235521F9E12 for ; Mon, 8 Jul 2013 14:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.913 X-Spam-Level: X-Spam-Status: No, score=-4.913 tagged_above=-999 required=5 tests=[AWL=-2.314, BAYES_00=-2.599] 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 NNDS5qJvZeg8 for ; Mon, 8 Jul 2013 14:03:51 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 421D921F9E13 for ; Mon, 8 Jul 2013 14:03:49 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3D2B5791E4; Mon, 8 Jul 2013 17:03:18 -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 669F3791DC for ; Mon, 8 Jul 2013 17:02:51 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPM00093YGHKVW0@mail-out.apple.com> for ipp@pwg.org; Mon, 08 Jul 2013 14:02:51 -0700 (PDT) X-AuditID: 11807153-b7f3c6d000007b32-21-51db28f94197 Received: from [17.153.30.174] (Unknown_Domain [17.153.30.174]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 3C.E6.31538.AF82BD15; Mon, 08 Jul 2013 14:02:51 -0700 (PDT) From: Michael Sweet Date: Mon, 08 Jul 2013 17:02:48 -0400 To: ipp@pwg.org Message-id: X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLJMWRmVeSWpSXmKPExsUiOFNune5vjduBBj23+CyO7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAldH84BFrwTTmim2LWtgaGM8xdTFyckgImEi0 nbzNBmGLSVy4tx7I5uIQEuhlkuhrXMMIkmATUJP4PamPFcRmFtCSuPHvJROELS+x/e0cZhCb RUBFYsGHxSwgtrCAhUTzzPdgvSIC/BITL4L0cnDwCthIPJ2bAxLmFTCQWH74GivEXnmJzobX rBMYeWYh2TALyYZZSFoWMDKvYhQoSs1JrDTWSywoyEnVS87P3cQICpSGwuAdjH+WWR1iFOBg VOLh/XD5VqAQa2JZcWXuIUYJDmYlEd4XqrcDhXhTEiurUovy44tKc1KLDzFKc7AoifNmqQOl BNITS1KzU1MLUotgskwcnFINjKsW+Sx9acVWEtJQNi2qWvX9jpBXscVr3M90bezTnHB1Q2PI JOHiVsG/FzkZ4pUUQ105OpZ0rTM5v7tmzcq9+0v4nhrEXZmV1Pvvkp0M/8z66yV1P1q7ZSbf UDc7EHXEXU0sKMue4Z5gYO/9SSmr5l3P2C966kXLB7Pjgc6TxDc8F/64p/ysphJLcUaioRZz UXEiAKBsjBYQAgAA X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes posted from today's IPP 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: , 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: 3D2B5791E4.A912D X-pwg-MailScanner-From: ipp-bounces@pwg.org 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-20130708.pdf Our next conference call is July 22, 2013 at 3pm ET. New action item: - Mike to post last call review draft of IPP FaxOut _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 8 23:16:26 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0621F9E9D for ; Mon, 8 Jul 2013 23:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6] 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 xAvxfoJ9Hy-h for ; Mon, 8 Jul 2013 23:16:20 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id C949221F9F52 for ; Mon, 8 Jul 2013 23:16:19 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B5250791F0; Tue, 9 Jul 2013 02:15:40 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mo.mxl.2iij.net (mo1500.mxl.2iij.net [203.180.99.16]) by pwg.org (Postfix) with ESMTP id 0D7F8791E8 for ; Tue, 9 Jul 2013 02:15:12 -0400 (EDT) Received: by mo.mxl.2iij.net (mxl-mo1500) id r696F9ho003867; Tue, 9 Jul 2013 15:15:09 +0900 Received: from unknown [210.173.21.247] (EHLO mx04.fujixerox.co.jp) by mas1507a.mxl.2iij.net(mxl_mta-6.15.0-6) over TLS secured channel with ESMTP id d6aabd15.0.226988.00-2349.403304.mas1507a.mxl.2iij.net (envelope-from ); Tue, 09 Jul 2013 15:15:09 +0900 (JST) X-MXL-Hash: 51dbaa6d7e70240c-811af81e60f405ddde368b171ca94b697114699c Received: from ma11.fujixerox.co.jp ([143.94.100.182]) by mx04.fujixerox.co.jp with ESMTP id r696F87t008342; Tue, 9 Jul 2013 15:15:09 +0900 Received: from ma11.fujixerox.co.jp (root@localhost) by ma11.fujixerox.co.jp with ESMTP id r696F8n4009784; Tue, 9 Jul 2013 15:15:08 +0900 Received: from unknown [143.94.100.180] by ma11.fujixerox.co.jp with ESMTP id RAA09780; Tue, 9 Jul 2013 15:15:08 +0900 Received: from exg01.kdc.fujixerox.co.jp ([143.94.250.171]) by ms2.dc.fxis.co.jp (8.13.8/8.13.8) with ESMTP id r696F6YL020114; Tue, 9 Jul 2013 15:15:08 +0900 (JST) Received: from FX-JPN-EXMBV03.dc00.fujixerox.net ([143.94.250.54]) by FX-JPN-EXHCS12.dc00.fujixerox.net ([172.25.1.201]) with mapi; Tue, 9 Jul 2013 15:15:08 +0900 From: fx OHTAKE SHIN To: Michael Sweet , "Manchala, Daniel" Date: Tue, 9 Jul 2013 15:15:32 +0900 Subject: RE: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Topic: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Index: Ac5znf//GOH003aTQzGW6t0KSwFcuwIy/PyQ Message-ID: <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> In-Reply-To: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 X-Spam: exempt X-MAIL-FROM: X-SOURCE-IP: [210.173.21.247] 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="===============1532240739==" 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: B5250791F0.A9850 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1532240739== Content-Language: ja-JP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0266_01CE7CB7.27A3F900" ------=_NextPart_000_0266_01CE7CB7.27A3F900 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Hi Mike-san, I've returned to my office, so let's discuss again. My understanding may not be so enough because we've past a week. We should discus with ITU-T.30 recommendations(facsimile protocols), instead of AT commands or PWG 5107.3. Because ITU-T.30 is the reference of FAX protocol, and in the world, there are too many facsimiles do not control by AT commands. CUPS is one of many IPP client implementations, also. Regards, Shin // --------------------------------------------------------------------- Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. phone: +81-45-755-5474 (direct) mail: shin.ohtake@fujixerox.co.jp --------------------------------------------------------------------- > -----Original Message----- > From: Michael Sweet [mailto:msweet@apple.com] > Sent: Friday, June 28, 2013 10:22 AM > To: Manchala, Daniel > Cc: fx OHTAKE SHIN; 'ipp@pwg.org' > Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments > > Daniel, > > On 2013-06-27, at 8:26 PM, "Manchala, Daniel" wrote: > > I think renaming both 'fax-modem-carrier-lost' and 'fax-modem-training-failure' to something like > 'fax-modem-confirmation-not-received' or 'fax-out-modem-confirmation-not-received' would help. The reasoning is as > follows: > > These names have already been approved (5107.3) and are in use (CUPS, which provided prototyping specifically for > the preliminary fax support via efax). > > Like I've said on many occasions, we can change the definitions all we like, but unless we want the mess of supporting > deprecated old names plus semantically identical new names I don't see the point in continuing discussion of changing > the names. > > As for fax-in-* and fax-out-*, there are enough common states between receiver and sender that I would not want to > double things up. > > > > As part of training (speed or data rate such as 9600bps) and at the end of it, a TCF (Training Check Flag) is sent > from the fax-out (sending) device to a fax-in (receiving) device. If there is a training failure, an FTT (Failure > to Train) is sent back from the fax-in receiving device to the fax-out sending device. If there is no training failure, > a CFR (Confirmation to Receive) is sent from the fax-in receiving device to the fax-out sending device. After sufficient > number of training failures (usually 3), a DCN (Disconnect) signal is sent from fax-out device to fax-in device and > the transmission stops. > > > > Likewise, if carrier is lost, there is no response received in terms of MCF (Message Confirmation) from fax-in device > at the fax-out device. > > > > In either of the two cases, a failure to detect/receive CFR or MCF from the fax-in device at the fax-out device > can trigger 'fax-out-modem-confirmation-not-received'. This is how the sending end will indicate that it lost its > connection to the receiver. > > > > We still could have 'fax-modem-carrier-lost', but on the receiving device, and probably it is good to rename it > as 'fax-in-modem-carrier-lost' indicating that this is an error on the fax-in device. Likewise, we could have > 'fax-modem-training-failure' but on the receiving device only and it is good to rename it (something) as > 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. > > > > I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be less confusing as to what mode a device is acting > (as a sender or receiver). > > > > Thanks, > > Daniel. > > > > > > > > -----Original Message----- > > From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of > > Michael Sweet > > Sent: Thursday, June 27, 2013 5:07 AM > > To: fx OHTAKE SHIN > > Cc: ipp@pwg.org > > Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > > specification and has comments > > > > Shin, > > > > Thanks for your comments! > > > > Responses inline... > > > > On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN wrote: > >> Greetings, > >> > >> Fuji Xerox has comments for the IPP FaxOut specification final call. > >> > >> ---- > >> 8.2 job-state-reasons > >> 1. fax-modem-carrier-lost > >> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost > >> by Called terminal. We think fax-modem-carrier-lost should be removed from the specification. > >> If the specification supposes another case, tell us an example on the facsimile protocol sequence. > > > > But on the sending end we still need an indication that we lost the connection to the receiver. Would changing > the definition here to something like "Lost connection to the receiver during send." be more descriptive? > > > > (in AT command set parlance, this would be a "NO CARRIER" response, > > received when the connection is lost) > > > >> 2. fax-modem-training-failure > >> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is > >> detected by Called terminal. We think fax-modem-training-failure should be removed from the specification. > >> If the specification supposes another case, tell us an example on the facsimile protocol sequence. > > > > But on the sending end we still need an indication that we were unable to connect to the receiver after the receiver > answered the call. This definition has already been updated once, but I am happy to reword it again to make this clear > - basically, 'fax-modem-training-failure' means that the receiver answered, the sender got the carrier tone, but the > sender and receiver were unable to successfully negotiate a data rate. > > > > (in AT command set parlance, this is also a "NO CARRIER" response, > > received after dialing) > > > >> 3. fax-modem-voice-detected > >> If fax-modem-voice-detected specified as a job state, it should > >> change name to job-calling. Facsimile always detect sound other than > >> a carrier tone while facsimile dialing numbers to detecting any > >> facsimile signals, because facsimile may hear ringing tone or machine's voice(voice answer system), human's voice(fax > manual receive). Therefore, fax-modem-voice-detected cannot specify as an error job reason, because of ringing tone. > > > > I'm not sure I understand your comment, but a couple things: > > > > 1. We can't change the names of these keywords: they were defined and > > approved last year as part of the Printer MIB and IPP MFD Alerts spec > > (PWG 5107.3-2012). Which of course I don't have referenced and am > > re-defining the names in the IANA section (editorial changes at > > least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP > > registrations] > > > > 2. We do want a way to indicate when the receiver answers but does not respond with a carrier within the connection > timeout setup in the modem. Again, falling back on the AT command set I would probably just get a "NO CARRIER" response > and a hang-up, but some modems did/do report "DELAYED" for the additional rings - we *could* add a keyword for that > ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this one as-is even if many implementations can't > support 'fax-modem-voice-detected'. > > > > 3. None of these are unconditionally required to implement - certain > > keywords depend on hardware features that may not be supported by your > > products, and so naturally you won't report those (similar to how you > > might not have a duplexing unit in your printer and thus don't have to > > report or support the "sides" attribute...) > > > > _________________________________________________________ > > 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 ------=_NextPart_000_0266_01CE7CB7.27A3F900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIPQzCCA1owggJCoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwUDELMAkG A1UEBhMCSlAxGDAWBgNVBAoTD1NFQ09NIFRydXN0Lm5ldDEnMCUGA1UECxMe U2VjdXJpdHkgQ29tbXVuaWNhdGlvbiBSb290Q0ExMB4XDTAzMDkzMDA0MjA0 OVoXDTIzMDkzMDA0MjA0OVowUDELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD1NF Q09NIFRydXN0Lm5ldDEnMCUGA1UECxMeU2VjdXJpdHkgQ29tbXVuaWNhdGlv biBSb290Q0ExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs7P+ f9Ntse8WfFelDG12ii9Lv2T7TO6K8PMpfPX/7irg6em6W2QimppvLDomaVEF mSbc1RxqccaafR6d3XxsxoxnZ0o++HGwGSepCQymlb9LjAz6VZg72OgioUtx OHmsl5Jps4l+6iFoBpgUlofSYTa8bSdWnlfuwMBW/TLPpNmOwiPXjajz2CWs l+RwOPS2OrSdO5cmQ6OhvElZckwjMIcBWPZOvhxoVmavzUFdyLNNKlVGqx/a HuJAPdvNfbmSgJw33QyWZJ3cIvdki99h3hWUUhWgfVLJS6ghycax7cvDlWDR D/CrcPjfy01+7Nb6q9m9f1Typel5+tnWdiQocwIDAQABoz8wPTAdBgNVHQ4E FgQUoHNJmWjchVtl45soL1efvTO8B0gwCwYDVR0PBAQDAgEGMA8GA1UdEwEB /wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAGhAqai75E9debMFtRezYBPr xpJd4NHTav77vpttv8cFbVkgxBzwt9qEWAJj+kgW70+lC/dKmPI/nhutR2tj zghH61I/eJyvTa741U/PmpgqEEE5UsTd2ZsO75MBrrIuymhCJEJssLM6Ps3p 2kjEFcvp+QcPklBJit0xl1/J6TeqO1lll5QyybOfPjpiWMVJrWIOcaUyqi/G iXZDQBMTZz2iVCUQy/E68tn620lWu6b+p0E1w+CIYcmIx982ECKYWeqwSvtW FnNurE33IqFPrR16LUUn5TDBXvLaE8slQlGVRwOMbCHMdELtU/8zi48PVwEW L8+m7slwIhS9/b5sCwMwggOoMIICkKADAgECAghDZzmIviunRjANBgkqhkiG 9w0BAQUFADA/MQswCQYDVQQGEwJKUDETMBEGA1UEChMKRnVqaSBYZXJveDEb MBkGA1UEAxMSRnVqaSBYZXJveCBYbmV0IENBMB4XDTEyMDQwMjA4MjY1N1oX DTE0MDQwMTE0NTk1OVowSDELMAkGA1UEBhMCSlAxHTAbBgNVBAoTFEZ1amkg WGVyb3ggQ28uLCBMdGQuMRowGAYDVQQDExEyMjE0NiBTaGluIE9odGFrZTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoyYpIZWaOHMB3ikbUlamQSCT y1neW2nOWCamO5N96DwcKvnQ2EHZQfpDDmhZAjzQQ5IGpM/iuH4eQo2sZ+2E Q8gevzVDJW5nU2ypvT+yteWg/Qq6MzJjZLa4+Apt+rQVBrXBZeywXEI8vA/R 4HWIEVM/EqbxhIDssJNQYz2Foy8CAwEAAaOCASEwggEdMB8GA1UdIwQYMBaA FE2I1t2VWHXrrYgbTTIISciCBGCOMAkGA1UdEwQCMAAwPQYDVR0fBDYwNDAy oDCgLoYsaHR0cDovL2NhcHMuZnVqaXhlcm94LmNvLmpwL2NybC9meHhuZXRj YS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAsGA1UdDwQE AwIFoDBcBgNVHSAEVTBTMFEGCysGAQQBgikBBQEGMEIwQAYIKwYBBQUHAgEW NGh0dHA6Ly93d3cuZnVqaXhlcm94LmNvLmpwL3Byb2R1Y3QvY2FwL2Z4eG5l dGNhLmh0bWwwJgYDVR0RBB8wHYEbc2hpbi5vaHRha2VAZnVqaXhlcm94LmNv LmpwMA0GCSqGSIb3DQEBBQUAA4IBAQA9Uba8PJmVy+YCm0MRvfwSjE869c9o VrUj8KmXtOdkRp5A/wsVl1wJwSY95Zo97NzLgOynIp9k8ra4cKuqkirhJFOw lE6DUWpKi05fsZtHkgG/lhuv3b6haJMkjWlYikXWIRJ7TTK0cNIxsY8wobAG mMAwASc9bzKjs6GLkPFFuqOBUNL/k2NGbvNLlstrM6wN928GZWffgFm0aLM9 OOvdhQeZanEqoBWwhCI/2n3GmYA27W/V8Guf+a/E9nhcCKZIKR5+h8tXCaox D2tx3kV9xpO1NymsQsyLrHTpwwgvZNU0+TH1nUNFNlqLmxELy+X9ORzaMYqk PeGa9jQLvUWyMIIECzCCAvOgAwIBAgIJAUWZhr9bgFB4MA0GCSqGSIb3DQEB BQUAME8xCzAJBgNVBAYTAkpQMRMwEQYDVQQKEwpGdWppIFhlcm94MSswKQYD VQQDEyJGdWppIFhlcm94IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4 MDQyOTE1MDAwMFoXDTE0MTIxNzAyMTMzMlowPzELMAkGA1UEBhMCSlAxEzAR BgNVBAoTCkZ1amkgWGVyb3gxGzAZBgNVBAMTEkZ1amkgWGVyb3ggWG5ldCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALV3iwzXlyB/xU98 aMEFsuTOg+ogQ903jg9N3md69FGcOgR4hN6f3n90z1d3yfy2CY/p11X2KIMm xth6CZYiporeXYwOGqgCie2cbZV09YISemQjKbavqk9wqsTR+IE/5+bdnY7s sbN0F06m+UmktqrcLl5AwTBb/fIA4NPy1gaFkFCub4zOnUHF9meIzkxq63LK Tmif48ZbI1frSF7HBGuJGaqTsHtBqvetbe+Nn15OcXrNwT7YdniukhqEWYSc qUnfNCjNWGp0viZB6a3wY7gOvsAT41OlWUrb5rCnDPbzCBojdWBBZB/QSNJq fgFgEhsLQh52/abm6f5d5UM9O10CAwEAAaOB+TCB9jALBgNVHQ8EBAMCAQYw HQYDVR0OBBYEFE2I1t2VWHXrrYgbTTIISciCBGCOMB8GA1UdIwQYMBaAFOrF p1bEKFI+gqXs9VAWY4/hiC15MFgGA1UdIARRME8wTQYLKwYBBAGCKQEFAQEw PjA8BggrBgEFBQcCARYwaHR0cDovL3d3dy5mdWppeGVyb3guY28uanAvcHJv ZHVjdC9jYXAvZnhjYS5odG1sMBIGA1UdEwEB/wQIMAYBAf8CAQAwOQYDVR0f BDIwMDAuoCygKoYoaHR0cDovL2NhcHMuZnVqaXhlcm94LmNvLmpwL2NybC9m eGNhLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAFfsmaMGjMqu0zTEvvAg/vkiP wzwCS3JwvTaH2R40sjZryCCN4e6yvm4aZHb86vzl/ngARXPh7lm3EMbMIMp9 M3EJhgvPgwxKH153+F31rKEPwaNWo3pQGxR7P8JxIOujZfSBoNL/bAqz+OZc I3B/LGhW6DTB4Qpatt4GZuf139CeMtW/qncnfY1snLHMlWsYzYn64+h69FwO B9ngfM6boxV3/sYAPGzjBH4IIlQ/1rpAWlIyEHoxQ15S/lVqclw7QC9D9giB Wv4/sy+80ZXsjVmhtTs42vJY3OWCy+3k0QDWNaDKlVzcmiAKWbd5jh2Ju8Im +PdmzsrEr4oEKHZyuTCCBCYwggMOoAMCAQICBBK5sKcwDQYJKoZIhvcNAQEF BQAwUDELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD1NFQ09NIFRydXN0Lm5ldDEn MCUGA1UECxMeU2VjdXJpdHkgQ29tbXVuaWNhdGlvbiBSb290Q0ExMB4XDTA0 MTIxNzAyMTMzMloXDTE0MTIxNzAyMTMzMlowTzELMAkGA1UEBhMCSlAxEzAR BgNVBAoTCkZ1amkgWGVyb3gxKzApBgNVBAMTIkZ1amkgWGVyb3ggQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC3JDX7X4x3kY0YJbxMy2IbuJf7EshbOGJRnAQ3kT3GjMYdIHJM1+27 Mf+BO8XeSQx3FL0kExFylc1hkreCJ0CtZ3dpm/VGOxtIFgdySgi4XVp0qnnA QSjUk9amAXHUNs52UqkTPKPOq9UPkLhcw5XEOZptkHAsmNdla1aDB/iTr2m9 n/8IKAY+BLM3FhW4tBbbV5wPlDq71B7yTtnHdJqarPBp/lvngARpHWvbcQ4m fRRb1JaiiWKLHW+0V0ojwN754unS9fGY+WqM3l9gb26AYDI3JPzthJpxyhtu c5EmP3FjFmuRpK/Unqt8h8nBlqJ90GgY09qQvULrG36uiweZAgMBAAGjggEH MIIBAzAdBgNVHQ4EFgQU6sWnVsQoUj6Cpez1UBZjj+GILXkwHwYDVR0jBBgw FoAUoHNJmWjchVtl45soL1efvTO8B0gwEgYDVR0TAQH/BAgwBgEB/wIBATAO BgNVHQ8BAf8EBAMCAQYwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL3JlcG9z aXRvcnkuc2Vjb210cnVzdC5uZXQvU0MtUm9vdDEvU0NSb290MUNSTC5jcmww UgYDVR0gBEswSTBHBgoqgwiMmxtkhwUBMDkwNwYIKwYBBQUHAgEWK2h0dHBz Oi8vcmVwb3NpdG9yeS5zZWNvbXRydXN0Lm5ldC9TQy1Sb290MS8wDQYJKoZI hvcNAQEFBQADggEBAC3KeO2cIQO9t9UJXBPA4rbR4uxVxoqm8E4V34Em3CTB ZqZCJi1H9nkHBJ1dfRHctmb9vqG7LcPDMpSRHtKHYrOZAK/X4PTa7sK8ahVI 0+LaKmMnicff0xicQeVvPm6vbk7VKFRGqgaHm34AFy1Mb+Wp8W2XFZVwnBcZ RRgqfHsrYf4tkyGCMVh8H/f5QmExhyIGu9wS52rQPeLzA4BtIhC47a6aGgSx wfFK0ccMZlR974bDma+6Vb4hqzi1u9Aj5WtPiJ5x2+uRwWPlD0qjS0BMZ8x3 YvWfo5vB2pWz/jaT2fefw4WQiWFBKVPMXA2oE0v6T98qkSNEoGxMJ3eMS6Ax ggJ1MIICcQIBATBLMD8xCzAJBgNVBAYTAkpQMRMwEQYDVQQKEwpGdWppIFhl cm94MRswGQYDVQQDExJGdWppIFhlcm94IFhuZXQgQ0ECCENnOYi+K6dGMAkG BSsOAwIaBQCgggGAMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDcwOTA2MTUzMlowIwYJKoZIhvcNAQkEMRYEFDY/Zzq0 4uL2ro3Au9ciUmT+SXtxMFoGCSsGAQQBgjcQBDFNMEswPzELMAkGA1UEBhMC SlAxEzARBgNVBAoTCkZ1amkgWGVyb3gxGzAZBgNVBAMTEkZ1amkgWGVyb3gg WG5ldCBDQQIIQ2c5iL4rp0YwXAYLKoZIhvcNAQkQAgsxTaBLMD8xCzAJBgNV BAYTAkpQMRMwEQYDVQQKEwpGdWppIFhlcm94MRswGQYDVQQDExJGdWppIFhl cm94IFhuZXQgQ0ECCENnOYi+K6dGMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3 DQEBAQUABIGAUnjfr23oGd0E/YgVGcwmlaSmAYSYQWTFguiNwgCrnh0Qy0y7 lyvLx8T/1OxnZrn+3FDkyMidesb1yqb3eK+KxieW7vGRr3q4+UzEqmQwMTsJ JmVNYRONFxyzv5dPyb+YcFJNH0ViHU6smB/DT8xcuzXJWs6OlbayS2pqtr72 WZkAAAAAAAA= ------=_NextPart_000_0266_01CE7CB7.27A3F900-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============1532240739== 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 --===============1532240739==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Tue Jul 9 08:07:58 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A721F9EB5 for ; Tue, 9 Jul 2013 08:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=-3.188, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6] 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 RpcyR0BlLRX0 for ; Tue, 9 Jul 2013 08:07:53 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id C408521F9EAA for ; Tue, 9 Jul 2013 08:07:52 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 4ECC3791FB; Tue, 9 Jul 2013 11:07:05 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id B1192791F9 for ; Tue, 9 Jul 2013 11:06:39 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPO007VGCLGEFJ1@mail-out.apple.com> for ipp@pwg.org; Tue, 09 Jul 2013 08:06:34 -0700 (PDT) X-AuditID: 1180715a-b7f506d000007d18-eb-51dc26f97d32 Received: from [17.153.23.238] (Unknown_Domain [17.153.23.238]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 77.EC.32024.9F62CD15; Tue, 09 Jul 2013 08:06:34 -0700 (PDT) Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments From: Michael Sweet In-reply-to: <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> Date: Tue, 09 Jul 2013 11:06:34 -0400 Message-id: References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> To: fx OHTAKE SHIN X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUiOFP8ne4vtTuBBt8PKlo83jGZ1eLYvpcs Fke+xVpMv7OCyYHFY+vJH2weH9cfZfaYt3g6k8fyU+vZAliiuGxSUnMyy1KL9O0SuDKam2+y Fyzwquh8dIixgfGWTRcjJ4eEgInEjJNLmCFsMYkL99azdTFycQgJ9DJJLJjdwAqSEBaIkHjx eRYLiM0roCex9N8cRhCbGcjecf0XWA2bgJrE70l9YDanQLRE04cbYDUsAioSF36chaoPltj3 ag4rhK0tsWzha2aImTYSP083QS2+wCRx41wz2DIRAQOJ+9NamLoYOYCuk5XY+TtpAiP/LCRn zEJyxiwkYxcwMq9iFChKzUmsNNNLLCjISdVLzs/dxAgKzYbCqB2MDcutDjEKcDAq8fAeULgT KMSaWFZcmXuIUYKDWUmEN4kPKMSbklhZlVqUH19UmpNafIhRmoNFSZzXWu92oJBAemJJanZq akFqEUyWiYNTqoHRo+Wtg2vTRh/N6XZrt2q8XuvscS/A493vr2uDM1lm35OzNlosVCWm2pCx 4ksRf8zNyXq6HNVr/qaEP5vwdMEGhg1b3s2p/tPxb+vJGU2qJy9fK2rdtuJMZXSK3YY5yqHF Tx6nn2Nxdzlx5UdF45ToILWLfl2+sRLspcaLIgXmXLlszV78o+2NEktxRqKhFnNRcSIANa3P cEkCAAA= X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "'ipp@pwg.org'" , "Manchala, Daniel" 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: 4ECC3791FB.AA033 X-pwg-MailScanner-From: ipp-bounces@pwg.org Shin, On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN wrote: > Hi Mike-san, > > I've returned to my office, so let's discuss again. > My understanding may not be so enough because we've past a week. > > We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3. > Because ITU-T.30 is the reference of FAX protocol, > and in the world, there are too many facsimiles do not control by AT commands. > CUPS is one of many IPP client implementations, also. We want keywords to define not only what is in T.30 but also what is possible/feasible to report in generate before, during, and after the fax session is negotiated. Right now we actually don't report a lot of the state information shown in the T.30 spec, and clearly some of the MFD Alert fax modem state keywords are not used by the sender... That said, we haven't made any of the new keywords required to support for IPP FaxOut. Like all "feature" keywords, the (implied) conditional requirement is that you use a standard keyword if you are reporting what that standard keyword represents, i.e., don't use a vendor keyword if a standard keyword exists. [Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int/rec/T-REC-T.30-200509-I/en] > > Regards, > Shin > // > --------------------------------------------------------------------- > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > phone: +81-45-755-5474 (direct) > mail: shin.ohtake@fujixerox.co.jp > --------------------------------------------------------------------- > > >> -----Original Message----- >> From: Michael Sweet [mailto:msweet@apple.com] >> Sent: Friday, June 28, 2013 10:22 AM >> To: Manchala, Daniel >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments >> >> Daniel, >> >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" wrote: >>> I think renaming both 'fax-modem-carrier-lost' and 'fax-modem-training-failure' to something like >> 'fax-modem-confirmation-not-received' or 'fax-out-modem-confirmation-not-received' would help. The reasoning is as >> follows: >> >> These names have already been approved (5107.3) and are in use (CUPS, which provided prototyping specifically for >> the preliminary fax support via efax). >> >> Like I've said on many occasions, we can change the definitions all we like, but unless we want the mess of supporting >> deprecated old names plus semantically identical new names I don't see the point in continuing discussion of changing >> the names. >> >> As for fax-in-* and fax-out-*, there are enough common states between receiver and sender that I would not want to >> double things up. >> >> >>> As part of training (speed or data rate such as 9600bps) and at the end of it, a TCF (Training Check Flag) is sent >> from the fax-out (sending) device to a fax-in (receiving) device. If there is a training failure, an FTT (Failure >> to Train) is sent back from the fax-in receiving device to the fax-out sending device. If there is no training failure, >> a CFR (Confirmation to Receive) is sent from the fax-in receiving device to the fax-out sending device. After sufficient >> number of training failures (usually 3), a DCN (Disconnect) signal is sent from fax-out device to fax-in device and >> the transmission stops. >>> >>> Likewise, if carrier is lost, there is no response received in terms of MCF (Message Confirmation) from fax-in device >> at the fax-out device. >>> >>> In either of the two cases, a failure to detect/receive CFR or MCF from the fax-in device at the fax-out device >> can trigger 'fax-out-modem-confirmation-not-received'. This is how the sending end will indicate that it lost its >> connection to the receiver. >>> >>> We still could have 'fax-modem-carrier-lost', but on the receiving device, and probably it is good to rename it >> as 'fax-in-modem-carrier-lost' indicating that this is an error on the fax-in device. Likewise, we could have >> 'fax-modem-training-failure' but on the receiving device only and it is good to rename it (something) as >> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. >>> >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be less confusing as to what mode a device is acting >> (as a sender or receiver). >>> >>> Thanks, >>> Daniel. >>> >>> >>> >>> -----Original Message----- >>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of >>> Michael Sweet >>> Sent: Thursday, June 27, 2013 5:07 AM >>> To: fx OHTAKE SHIN >>> Cc: ipp@pwg.org >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut >>> specification and has comments >>> >>> Shin, >>> >>> Thanks for your comments! >>> >>> Responses inline... >>> >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN wrote: >>>> Greetings, >>>> >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. >>>> >>>> ---- >>>> 8.2 job-state-reasons >>>> 1. fax-modem-carrier-lost >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost >>>> by Called terminal. We think fax-modem-carrier-lost should be removed from the specification. >>>> If the specification supposes another case, tell us an example on the facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we lost the connection to the receiver. Would changing >> the definition here to something like "Lost connection to the receiver during send." be more descriptive? >>> >>> (in AT command set parlance, this would be a "NO CARRIER" response, >>> received when the connection is lost) >>> >>>> 2. fax-modem-training-failure >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is >>>> detected by Called terminal. We think fax-modem-training-failure should be removed from the specification. >>>> If the specification supposes another case, tell us an example on the facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we were unable to connect to the receiver after the receiver >> answered the call. This definition has already been updated once, but I am happy to reword it again to make this clear >> - basically, 'fax-modem-training-failure' means that the receiver answered, the sender got the carrier tone, but the >> sender and receiver were unable to successfully negotiate a data rate. >>> >>> (in AT command set parlance, this is also a "NO CARRIER" response, >>> received after dialing) >>> >>>> 3. fax-modem-voice-detected >>>> If fax-modem-voice-detected specified as a job state, it should >>>> change name to job-calling. Facsimile always detect sound other than >>>> a carrier tone while facsimile dialing numbers to detecting any >>>> facsimile signals, because facsimile may hear ringing tone or machine's voice(voice answer system), human's voice(fax >> manual receive). Therefore, fax-modem-voice-detected cannot specify as an error job reason, because of ringing tone. >>> >>> I'm not sure I understand your comment, but a couple things: >>> >>> 1. We can't change the names of these keywords: they were defined and >>> approved last year as part of the Printer MIB and IPP MFD Alerts spec >>> (PWG 5107.3-2012). Which of course I don't have referenced and am >>> re-defining the names in the IANA section (editorial changes at >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP >>> registrations] >>> >>> 2. We do want a way to indicate when the receiver answers but does not respond with a carrier within the connection >> timeout setup in the modem. Again, falling back on the AT command set I would probably just get a "NO CARRIER" response >> and a hang-up, but some modems did/do report "DELAYED" for the additional rings - we *could* add a keyword for that >> ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this one as-is even if many implementations can't >> support 'fax-modem-voice-detected'. >>> >>> 3. None of these are unconditionally required to implement - certain >>> keywords depend on hardware features that may not be supported by your >>> products, and so naturally you won't report those (similar to how you >>> might not have a duplexing unit in your printer and thus don't have to >>> report or support the "sides" attribute...) >>> >>> _________________________________________________________ >>> 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 > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Jul 9 11:57:59 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B531F21F9D9C for ; Tue, 9 Jul 2013 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6] 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 xWTloIkRDPPR for ; Tue, 9 Jul 2013 11:57:54 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE6921F9D70 for ; Tue, 9 Jul 2013 11:57:54 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 797B2791FC; Tue, 9 Jul 2013 14:57:10 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR003.ACS-INC.COM (usa7109mr003.acs-inc.com [63.101.151.12]) by pwg.org (Postfix) with ESMTP id 92AC2791F0 for ; Tue, 9 Jul 2013 14:56:45 -0400 (EDT) Received: from usa7109ht001.na.xerox.net ([13.41.230.31]) by USA7109MR003.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 09 Jul 2013 13:56:32 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.17]) by USA7109HT001.na.xerox.net ([13.41.230.31]) with mapi id 14.02.0309.002; Tue, 9 Jul 2013 13:56:32 -0500 From: "Manchala, Daniel" To: Michael Sweet , fx OHTAKE SHIN Subject: RE: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Topic: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Index: AQHOfLX4q9CUC4v//Ey5LFt95defZZlcsRHV Date: Tue, 9 Jul 2013 18:56:31 +0000 Message-ID: References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.95.25.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean 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: 797B2791FC.A9ADC X-pwg-MailScanner-From: ipp-bounces@pwg.org Mike, I think what Shin is trying to say is that there is an impossibility of a F= axOut Device to detect such things as training failure or lost carrier. The= se are generally detected by a receiving facsimile and a sending FaxOut can= at best guess based on timeouts in receiving a response. (Shin, please cla= rify if I understood what you are implying). Daniel. ________________________________________ From: Michael Sweet [msweet@apple.com] Sent: Tuesday, July 09, 2013 8:06 AM To: fx OHTAKE SHIN Cc: Manchala, Daniel; 'ipp@pwg.org' Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments Shin, On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN wro= te: > Hi Mike-san, > > I've returned to my office, so let's discuss again. > My understanding may not be so enough because we've past a week. > > We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3. > Because ITU-T.30 is the reference of FAX protocol, > and in the world, there are too many facsimiles do not control by AT comm= ands. > CUPS is one of many IPP client implementations, also. We want keywords to define not only what is in T.30 but also what is possib= le/feasible to report in generate before, during, and after the fax session= is negotiated. Right now we actually don't report a lot of the state infor= mation shown in the T.30 spec, and clearly some of the MFD Alert fax modem = state keywords are not used by the sender... That said, we haven't made any of the new keywords required to support for = IPP FaxOut. Like all "feature" keywords, the (implied) conditional requirem= ent is that you use a standard keyword if you are reporting what that stand= ard keyword represents, i.e., don't use a vendor keyword if a standard keyw= ord exists. [Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int= /rec/T-REC-T.30-200509-I/en] > > Regards, > Shin > // > --------------------------------------------------------------------- > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > phone: +81-45-755-5474 (direct) > mail: shin.ohtake@fujixerox.co.jp > --------------------------------------------------------------------- > > >> -----Original Message----- >> From: Michael Sweet [mailto:msweet@apple.com] >> Sent: Friday, June 28, 2013 10:22 AM >> To: Manchala, Daniel >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specificat= ion and has comments >> >> Daniel, >> >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" wrote: >>> I think renaming both 'fax-modem-carrier-lost' and 'fax-modem-training-= failure' to something like >> 'fax-modem-confirmation-not-received' or 'fax-out-modem-confirmation-not= -received' would help. The reasoning is as >> follows: >> >> These names have already been approved (5107.3) and are in use (CUPS, wh= ich provided prototyping specifically for >> the preliminary fax support via efax). >> >> Like I've said on many occasions, we can change the definitions all we l= ike, but unless we want the mess of supporting >> deprecated old names plus semantically identical new names I don't see t= he point in continuing discussion of changing >> the names. >> >> As for fax-in-* and fax-out-*, there are enough common states between re= ceiver and sender that I would not want to >> double things up. >> >> >>> As part of training (speed or data rate such as 9600bps) and at the end= of it, a TCF (Training Check Flag) is sent >> from the fax-out (sending) device to a fax-in (receiving) device. If the= re is a training failure, an FTT (Failure >> to Train) is sent back from the fax-in receiving device to the fax-out s= ending device. If there is no training failure, >> a CFR (Confirmation to Receive) is sent from the fax-in receiving device= to the fax-out sending device. After sufficient >> number of training failures (usually 3), a DCN (Disconnect) signal is se= nt from fax-out device to fax-in device and >> the transmission stops. >>> >>> Likewise, if carrier is lost, there is no response received in terms of= MCF (Message Confirmation) from fax-in device >> at the fax-out device. >>> >>> In either of the two cases, a failure to detect/receive CFR or MCF from= the fax-in device at the fax-out device >> can trigger 'fax-out-modem-confirmation-not-received'. This is how the = sending end will indicate that it lost its >> connection to the receiver. >>> >>> We still could have 'fax-modem-carrier-lost', but on the receiving devi= ce, and probably it is good to rename it >> as 'fax-in-modem-carrier-lost' indicating that this is an error on the f= ax-in device. Likewise, we could have >> 'fax-modem-training-failure' but on the receiving device only and it is = good to rename it (something) as >> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. >>> >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be les= s confusing as to what mode a device is acting >> (as a sender or receiver). >>> >>> Thanks, >>> Daniel. >>> >>> >>> >>> -----Original Message----- >>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of >>> Michael Sweet >>> Sent: Thursday, June 27, 2013 5:07 AM >>> To: fx OHTAKE SHIN >>> Cc: ipp@pwg.org >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut >>> specification and has comments >>> >>> Shin, >>> >>> Thanks for your comments! >>> >>> Responses inline... >>> >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN wrote: >>>> Greetings, >>>> >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. >>>> >>>> ---- >>>> 8.2 job-state-reasons >>>> 1. fax-modem-carrier-lost >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost >>>> by Called terminal. We think fax-modem-carrier-lost should be removed = from the specification. >>>> If the specification supposes another case, tell us an example on the = facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we lost the con= nection to the receiver. Would changing >> the definition here to something like "Lost connection to the receiver d= uring send." be more descriptive? >>> >>> (in AT command set parlance, this would be a "NO CARRIER" response, >>> received when the connection is lost) >>> >>>> 2. fax-modem-training-failure >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is >>>> detected by Called terminal. We think fax-modem-training-failure shoul= d be removed from the specification. >>>> If the specification supposes another case, tell us an example on the = facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we were unable = to connect to the receiver after the receiver >> answered the call. This definition has already been updated once, but I = am happy to reword it again to make this clear >> - basically, 'fax-modem-training-failure' means that the receiver answer= ed, the sender got the carrier tone, but the >> sender and receiver were unable to successfully negotiate a data rate. >>> >>> (in AT command set parlance, this is also a "NO CARRIER" response, >>> received after dialing) >>> >>>> 3. fax-modem-voice-detected >>>> If fax-modem-voice-detected specified as a job state, it should >>>> change name to job-calling. Facsimile always detect sound other than >>>> a carrier tone while facsimile dialing numbers to detecting any >>>> facsimile signals, because facsimile may hear ringing tone or machine'= s voice(voice answer system), human's voice(fax >> manual receive). Therefore, fax-modem-voice-detected cannot specify as a= n error job reason, because of ringing tone. >>> >>> I'm not sure I understand your comment, but a couple things: >>> >>> 1. We can't change the names of these keywords: they were defined and >>> approved last year as part of the Printer MIB and IPP MFD Alerts spec >>> (PWG 5107.3-2012). Which of course I don't have referenced and am >>> re-defining the names in the IANA section (editorial changes at >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP >>> registrations] >>> >>> 2. We do want a way to indicate when the receiver answers but does not = respond with a carrier within the connection >> timeout setup in the modem. Again, falling back on the AT command set I = would probably just get a "NO CARRIER" response >> and a hang-up, but some modems did/do report "DELAYED" for the additiona= l rings - we *could* add a keyword for that >> ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this o= ne as-is even if many implementations can't >> support 'fax-modem-voice-detected'. >>> >>> 3. None of these are unconditionally required to implement - certain >>> keywords depend on hardware features that may not be supported by your >>> products, and so naturally you won't report those (similar to how you >>> might not have a duplexing unit in your printer and thus don't have to >>> report or support the "sides" attribute...) >>> >>> _________________________________________________________ >>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>> >>> >>> -- >>> This message has been scanned for viruses and dangerous content by Mail= Scanner, 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 > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Jul 9 13:15:45 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C444F21F8FDC for ; Tue, 9 Jul 2013 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oLUDhbF29b2 for ; Tue, 9 Jul 2013 13:15:41 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0004421F84E3 for ; Tue, 9 Jul 2013 13:15:40 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 1ACBF79206; Tue, 9 Jul 2013 16:15:02 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by pwg.org (Postfix) with ESMTP id 8CB83791D6 for ; Tue, 9 Jul 2013 16:14:39 -0400 (EDT) Received: by mail-ie0-f170.google.com with SMTP id e11so13815817iej.15 for ; Tue, 09 Jul 2013 13:14:39 -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=I8UApdSvYtiLhIc+glq+Jwy0ZpMtNthhUmDb8BH93pQ=; b=jm/p5OTd4VQio9ojra9NXCk1cUN/B77jVXEte+o3FSDXdm8BD+L+uMt8NGe1y0zoJN OgTP3VKNBOCHg+OCsSVVrv6kN12hmx79Jk40lD+Af9xa8yhwLQ1c7w0y8FytV4LPc3lV 8RVBXatFe+LqTLXeZXgrtiLiaCb58b+Dv22P9exd9dBYDX7edy6pJVlTCuXE+vz3Ud+N FwoaBUOsCAXrLye0KgxeAC09iioRquRfIjygwia10RZh9sfLv9+y5Sgylk/ZhkHXU5FD U35UA7WrGDtC5dk5WY1iZUgnwjQ8ZGTk6DWLh//EHwnasMPdv5z42ArZxVVal+am5fWu vCXA== MIME-Version: 1.0 X-Received: by 10.42.224.72 with SMTP id in8mr6808560icb.114.1373400878857; Tue, 09 Jul 2013 13:14:38 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Tue, 9 Jul 2013 13:14:38 -0700 (PDT) In-Reply-To: References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> Date: Tue, 9 Jul 2013 16:14:38 -0400 Message-ID: Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments From: Ira McDonald To: "Manchala, Daniel" 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="===============0301558756==" 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: 1ACBF79206.A9306 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0301558756== Content-Type: multipart/alternative; boundary=001a11331f2684c6e204e119cf2a --001a11331f2684c6e204e119cf2a Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel, But the same set of FaxModem subunit alerts (Printer MIB and IPP) MAY be used by either FaxOut or FaxIn or both - implementation choice. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel wrote: > Mike, > > I think what Shin is trying to say is that there is an impossibility of a > FaxOut Device to detect such things as training failure or lost carrier. > These are generally detected by a receiving facsimile and a sending FaxOut > can at best guess based on timeouts in receiving a response. (Shin, please > clarify if I understood what you are implying). > > Daniel. > ________________________________________ > From: Michael Sweet [msweet@apple.com] > Sent: Tuesday, July 09, 2013 8:06 AM > To: fx OHTAKE SHIN > Cc: Manchala, Daniel; 'ipp@pwg.org' > Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification > and has comments > > Shin, > > On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN > wrote: > > Hi Mike-san, > > > > I've returned to my office, so let's discuss again. > > My understanding may not be so enough because we've past a week. > > > > We should discus with ITU-T.30 recommendations(facsimile protocols), > > instead of AT commands or PWG 5107.3. > > Because ITU-T.30 is the reference of FAX protocol, > > and in the world, there are too many facsimiles do not control by AT > commands. > > CUPS is one of many IPP client implementations, also. > > We want keywords to define not only what is in T.30 but also what is > possible/feasible to report in generate before, during, and after the fax > session is negotiated. Right now we actually don't report a lot of the > state information shown in the T.30 spec, and clearly some of the MFD Alert > fax modem state keywords are not used by the sender... > > That said, we haven't made any of the new keywords required to support for > IPP FaxOut. Like all "feature" keywords, the (implied) conditional > requirement is that you use a standard keyword if you are reporting what > that standard keyword represents, i.e., don't use a vendor keyword if a > standard keyword exists. > > [Note for myself; Add normative reference to ITU-T.30 at > http://www.itu.int/rec/T-REC-T.30-200509-I/en] > > > > > > Regards, > > Shin > > // > > --------------------------------------------------------------------- > > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > > phone: +81-45-755-5474 (direct) > > mail: shin.ohtake@fujixerox.co.jp > > --------------------------------------------------------------------- > > > > > >> -----Original Message----- > >> From: Michael Sweet [mailto:msweet@apple.com] > >> Sent: Friday, June 28, 2013 10:22 AM > >> To: Manchala, Daniel > >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' > >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > specification and has comments > >> > >> Daniel, > >> > >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" < > Daniel.Manchala@xerox.com> wrote: > >>> I think renaming both 'fax-modem-carrier-lost' and > 'fax-modem-training-failure' to something like > >> 'fax-modem-confirmation-not-received' or > 'fax-out-modem-confirmation-not-received' would help. The reasoning is as > >> follows: > >> > >> These names have already been approved (5107.3) and are in use (CUPS, > which provided prototyping specifically for > >> the preliminary fax support via efax). > >> > >> Like I've said on many occasions, we can change the definitions all we > like, but unless we want the mess of supporting > >> deprecated old names plus semantically identical new names I don't see > the point in continuing discussion of changing > >> the names. > >> > >> As for fax-in-* and fax-out-*, there are enough common states between > receiver and sender that I would not want to > >> double things up. > >> > >> > >>> As part of training (speed or data rate such as 9600bps) and at the > end of it, a TCF (Training Check Flag) is sent > >> from the fax-out (sending) device to a fax-in (receiving) device. If > there is a training failure, an FTT (Failure > >> to Train) is sent back from the fax-in receiving device to the fax-out > sending device. If there is no training failure, > >> a CFR (Confirmation to Receive) is sent from the fax-in receiving > device to the fax-out sending device. After sufficient > >> number of training failures (usually 3), a DCN (Disconnect) signal is > sent from fax-out device to fax-in device and > >> the transmission stops. > >>> > >>> Likewise, if carrier is lost, there is no response received in terms > of MCF (Message Confirmation) from fax-in device > >> at the fax-out device. > >>> > >>> In either of the two cases, a failure to detect/receive CFR or MCF > from the fax-in device at the fax-out device > >> can trigger 'fax-out-modem-confirmation-not-received'. This is how the > sending end will indicate that it lost its > >> connection to the receiver. > >>> > >>> We still could have 'fax-modem-carrier-lost', but on the receiving > device, and probably it is good to rename it > >> as 'fax-in-modem-carrier-lost' indicating that this is an error on the > fax-in device. Likewise, we could have > >> 'fax-modem-training-failure' but on the receiving device only and it is > good to rename it (something) as > >> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. > >>> > >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be > less confusing as to what mode a device is acting > >> (as a sender or receiver). > >>> > >>> Thanks, > >>> Daniel. > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of > >>> Michael Sweet > >>> Sent: Thursday, June 27, 2013 5:07 AM > >>> To: fx OHTAKE SHIN > >>> Cc: ipp@pwg.org > >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > >>> specification and has comments > >>> > >>> Shin, > >>> > >>> Thanks for your comments! > >>> > >>> Responses inline... > >>> > >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN < > shin.ohtake@fujixerox.co.jp> wrote: > >>>> Greetings, > >>>> > >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. > >>>> > >>>> ---- > >>>> 8.2 job-state-reasons > >>>> 1. fax-modem-carrier-lost > >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost > >>>> by Called terminal. We think fax-modem-carrier-lost should be removed > from the specification. > >>>> If the specification supposes another case, tell us an example on the > facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we lost the > connection to the receiver. Would changing > >> the definition here to something like "Lost connection to the receiver > during send." be more descriptive? > >>> > >>> (in AT command set parlance, this would be a "NO CARRIER" response, > >>> received when the connection is lost) > >>> > >>>> 2. fax-modem-training-failure > >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is > >>>> detected by Called terminal. We think fax-modem-training-failure > should be removed from the specification. > >>>> If the specification supposes another case, tell us an example on the > facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we were unable > to connect to the receiver after the receiver > >> answered the call. This definition has already been updated once, but I > am happy to reword it again to make this clear > >> - basically, 'fax-modem-training-failure' means that the receiver > answered, the sender got the carrier tone, but the > >> sender and receiver were unable to successfully negotiate a data rate. > >>> > >>> (in AT command set parlance, this is also a "NO CARRIER" response, > >>> received after dialing) > >>> > >>>> 3. fax-modem-voice-detected > >>>> If fax-modem-voice-detected specified as a job state, it should > >>>> change name to job-calling. Facsimile always detect sound other than > >>>> a carrier tone while facsimile dialing numbers to detecting any > >>>> facsimile signals, because facsimile may hear ringing tone or > machine's voice(voice answer system), human's voice(fax > >> manual receive). Therefore, fax-modem-voice-detected cannot specify as > an error job reason, because of ringing tone. > >>> > >>> I'm not sure I understand your comment, but a couple things: > >>> > >>> 1. We can't change the names of these keywords: they were defined and > >>> approved last year as part of the Printer MIB and IPP MFD Alerts spec > >>> (PWG 5107.3-2012). Which of course I don't have referenced and am > >>> re-defining the names in the IANA section (editorial changes at > >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP > >>> registrations] > >>> > >>> 2. We do want a way to indicate when the receiver answers but does not > respond with a carrier within the connection > >> timeout setup in the modem. Again, falling back on the AT command set I > would probably just get a "NO CARRIER" response > >> and a hang-up, but some modems did/do report "DELAYED" for the > additional rings - we *could* add a keyword for that > >> ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this > one as-is even if many implementations can't > >> support 'fax-modem-voice-detected'. > >>> > >>> 3. None of these are unconditionally required to implement - certain > >>> keywords depend on hardware features that may not be supported by your > >>> products, and so naturally you won't report those (similar to how you > >>> might not have a duplexing unit in your printer and thus don't have to > >>> report or support the "sides" attribute...) > >>> > >>> _________________________________________________________ > >>> 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 > > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --001a11331f2684c6e204e119cf2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

But the same s= et of FaxModem subunit alerts (Printer MIB and IPP) MAY be used
by= either FaxOut or FaxIn or both - implementation choice.

Cheer= s,
- Ira


= Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Op= en 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 System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Tue, Jul 9, 2013 at 2:56 PM, Manchala= , Daniel <Daniel.Manchala@xerox.com> wrote:
Mike,

I think what Shin is trying to say is that there is an impossibility of a F= axOut Device to detect such things as training failure or lost carrier. The= se are generally detected by a receiving facsimile and a sending FaxOut can= at best guess based on timeouts in receiving a response. (Shin, please cla= rify if I understood what you are implying).

Daniel.
________________________________________
From: Michael Sweet [msweet@apple.com]
Sent: Tuesday, July 09, 2013 8:06 AM
To: fx OHTAKE SHIN
Cc: Manchala, Daniel; 'ipp@pwg.org&#= 39;
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments

Shin,

On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.jp> wrote:
> Hi Mike-san,
>
> I've returned to my office, so let's discuss again.
> My understanding may not be so enough because we've past a week. >
> We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3.
> Because ITU-T.30 is the reference of FAX protocol,
> and in the world, there are too many facsimiles do not control by AT c= ommands.
> CUPS is one of many IPP client implementations, also.

We want keywords to define not only what is in T.30 but also what is possib= le/feasible to report in generate before, during, and after the fax session= is negotiated. Right now we actually don't report a lot of the state i= nformation shown in the T.30 spec, and clearly some of the MFD Alert fax mo= dem state keywords are not used by the sender...

That said, we haven't made any of the new keywords required to support = for IPP FaxOut. Like all "feature" keywords, the (implied) condit= ional requirement is that you use a standard keyword if you are reporting w= hat that standard keyword represents, i.e., don't use a vendor keyword = if a standard keyword exists.

[Note for myself; Add normative reference to ITU-T.30 at http://www.itu.in= t/rec/T-REC-T.30-200509-I/en]


>
> Regards,
> Shin
> //
> ---------------------------------------------------------------------<= br> > Shin Ohtake =A0 =A0 CTPF4D, Fuji Xerox Co.,Ltd.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +81-45-755-5474 (direct)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mail: =A0shin.ohtake@fujixerox.co.jp
> ---------------------------------------------------------------------<= br> >
>
>> -----Original Message-----
>> From: Michael Sweet [mailto:ms= weet@apple.com]
>> Sent: Friday, June 28, 2013 10:22 AM
>> To: Manchala, Daniel
>> Cc: fx OHTAKE SHIN; 'ipp@pwg.or= g'
>> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut spec= ification and has comments
>>
>> Daniel,
>>
>> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" <Daniel.Manchala@xerox.com> wr= ote:
>>> I think renaming both 'fax-modem-carrier-lost' and = 9;fax-modem-training-failure' to something like
>> 'fax-modem-confirmation-not-received' or 'fax-out-mode= m-confirmation-not-received' would help. The reasoning is as
>> follows:
>>
>> These names have already been approved (5107.3) and are in use (CU= PS, which provided prototyping specifically for
>> the preliminary fax support via efax).
>>
>> Like I've said on many occasions, we can change the definition= s all we like, but unless we want the mess of supporting
>> deprecated old names plus semantically identical new names I don&#= 39;t see the point in continuing discussion of changing
>> the names.
>>
>> As for fax-in-* and fax-out-*, there are enough common states betw= een receiver and sender that I would not want to
>> double things up.
>>
>>
>>> As part of training (speed or data rate such as 9600bps) and a= t the end of it, a TCF (Training Check Flag) is sent
>> from the fax-out (sending) device to a fax-in (receiving) device. = If there is a training failure, an FTT (Failure
>> to Train) is sent back from the fax-in receiving device to the fax= -out sending device. If there is no training failure,
>> a CFR (Confirmation to Receive) is sent from the fax-in receiving = device to the fax-out sending device. After sufficient
>> number of training failures (usually 3), a DCN (Disconnect) signal= is sent from fax-out device to fax-in device and
>> the transmission stops.
>>>
>>> Likewise, if carrier is lost, there is no response received in= terms of MCF (Message Confirmation) from fax-in device
>> at the fax-out device.
>>>
>>> In either of the two cases, a failure to detect/receive CFR or= MCF from the fax-in device at the fax-out device
>> can trigger 'fax-out-modem-confirmation-not-received'. =A0= This is how the sending end will indicate that it lost its
>> connection to the receiver.
>>>
>>> We still could have 'fax-modem-carrier-lost', but on t= he receiving device, and probably it is good to rename it
>> as 'fax-in-modem-carrier-lost' indicating that this is an = error on the fax-in device. Likewise, we could have
>> 'fax-modem-training-failure' but on the receiving device o= nly and it is good to rename it (something) as
>> 'fax-in-modem-training-failure' or 'fax-in-modem-failu= re-to-train.
>>>
>>> I like to have the 'fax-out-*' and 'fax-in-*' = syntax as it would be less confusing as to what mode a device is acting
>> (as a sender or receiver).
>>>
>>> Thanks,
>>> Daniel.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ipp-bounces@pwg.o= rg [mailto:ipp-bounces@pwg.org] On Behalf Of
>>> Michael Sweet
>>> Sent: Thursday, June 27, 2013 5:07 AM
>>> To: fx OHTAKE SHIN
>>> Cc: ipp@pwg.org
>>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut
>>> specification and has comments
>>>
>>> Shin,
>>>
>>> Thanks for your comments!
>>>
>>> Responses inline...
>>>
>>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.jp> wrote:<= br> >>>> Greetings,
>>>>
>>>> Fuji Xerox has comments for the IPP FaxOut specification f= inal call.
>>>>
>>>> ----
>>>> 8.2 job-state-reasons
>>>> 1. fax-modem-carrier-lost
>>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carr= ier is lost
>>>> by Called terminal. We think fax-modem-carrier-lost should= be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we los= t the connection to the receiver. =A0Would changing
>> the definition here to something like "Lost connection to the= receiver during send." be more descriptive?
>>>
>>> (in AT command set parlance, this would be a "NO CARRIER&= quot; response,
>>> received when the connection is lost)
>>>
>>>> 2. fax-modem-training-failure
>>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training f= ailure is
>>>> detected by Called terminal. We think fax-modem-training-f= ailure should be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we wer= e unable to connect to the receiver after the receiver
>> answered the call. This definition has already been updated once, = but I am happy to reword it again to make this clear
>> - basically, 'fax-modem-training-failure' means that the r= eceiver answered, the sender got the carrier tone, but the
>> sender and receiver were unable to successfully negotiate a data r= ate.
>>>
>>> (in AT command set parlance, this is also a "NO CARRIER&q= uot; response,
>>> received after dialing)
>>>
>>>> 3. fax-modem-voice-detected
>>>> If fax-modem-voice-detected specified as a job state, it s= hould
>>>> change name to job-calling. Facsimile always detect sound = other than
>>>> a carrier tone while facsimile dialing numbers to detectin= g any
>>>> facsimile signals, because facsimile may hear ringing tone= or machine's voice(voice answer system), human's voice(fax
>> manual receive). Therefore, fax-modem-voice-detected cannot specif= y as an error job reason, because of ringing tone.
>>>
>>> I'm not sure I understand your comment, but a couple thing= s:
>>>
>>> 1. We can't change the names of these keywords: they were = defined and
>>> approved last year as part of the Printer MIB and IPP MFD Aler= ts spec
>>> (PWG 5107.3-2012). Which of course I don't have referenced= and am
>>> re-defining the names in the IANA section (editorial changes a= t
>>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP
>>> registrations]
>>>
>>> 2. We do want a way to indicate when the receiver answers but = does not respond with a carrier within the connection
>> timeout setup in the modem. Again, falling back on the AT command = set I would probably just get a "NO CARRIER" response
>> and a hang-up, but some modems did/do report "DELAYED" f= or the additional rings - we *could* add a keyword for that
>> ("fax-modem-delayed"? "fax-modem-waiting"?) bu= t I'd like to leave this one as-is even if many implementations can'= ;t
>> support 'fax-modem-voice-detected'.
>>>
>>> 3. None of these are unconditionally required to implement - c= ertain
>>> keywords depend on hardware features that may not be supported= by your
>>> products, and so naturally you won't report those (similar= to how you
>>> might not have a duplexing unit in your printer and thus don&#= 39;t have to
>>> report or support the "sides" attribute...)
>>>
>>> _________________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>
>>>
>>> --
>>> This message has been scanned for viruses and dangerous conten= t 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
>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


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

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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --001a11331f2684c6e204e119cf2a-- --===============0301558756== 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 --===============0301558756==-- From ipp-bounces@pwg.org Tue Jul 9 13:55:47 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794C021F9D58 for ; Tue, 9 Jul 2013 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=-2.355, BAYES_00=-2.599] 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 jekO7l7oHRrz for ; Tue, 9 Jul 2013 13:55:41 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2188D21F9273 for ; Tue, 9 Jul 2013 13:55:40 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 64B657920D; Tue, 9 Jul 2013 16:54:56 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by pwg.org (Postfix) with ESMTP id 92AC77920C for ; Tue, 9 Jul 2013 16:54:29 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPO0041NSQNIPI0@mail-out.apple.com> for ipp@pwg.org; Tue, 09 Jul 2013 13:54:26 -0700 (PDT) X-AuditID: 11807143-b7fe56d000007efd-a8-51dc7880a836 Received: from [17.153.30.10] (Unknown_Domain [17.153.30.10]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id F9.66.32509.1887CD15; Tue, 09 Jul 2013 13:54:26 -0700 (PDT) Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments From: Michael Sweet In-reply-to: Date: Tue, 09 Jul 2013 16:54:23 -0400 Message-id: <88245298-CAF5-4F8C-9641-FCCA17B89627@apple.com> References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> To: Daniel Manchala X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiOFOOS7ep4k6gQespfYvHOyazWhzb95LF 4si3WIvpd1YwObB4bD35g83j4/qjzB7zFk9n8lh+aj1bAEsUl01Kak5mWWqRvl0CV8aUeW9Z Cl6xV5yac425gXE5WxcjJ4eEgInE8y0NLBC2mMSFe+uB4lwcQgLdTBLN96eAFQkLREi8+DwL rIhXwEBi+eFrrCA2s4CWxI1/L5lAbDYBNYnfk/rA4pwCgRLzJ39l7GLk4GARUJH49g+q3Fdi wem3LBC2tsSyha+ZIUbaSEw9fBRq7zFmiZXr57OC9IoI6Eucv64KcZu8RGfDa9YJjPyzkFwx C8kVs5CMXcDIvIpRoCg1J7HSSC+xoCAnVS85P3cTIygwGwqddzAeW2Z1iFGAg1GJh/eAwp1A IdbEsuLK3EOMEhzMSiK8SXxAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwWercDhQTSE0tSs1NT C1KLYLJMHJxSDYzLTsvtXMG9qEkkRlNp7c86h9k3HkRE5e97sm97ZsapddO/3ONMi9f4/bIv p+kRa8Lno29lnK+veC6yx8zvF/9K//AnFR8an3y0NPObIbLia9pBxV+mp/kPtDzx2NbgLOjU b/rN89/UIu2LKXz/IpcL+krek9Vx2vt69iPmhRXTjtdJ7VOsEeFUYinOSDTUYi4qTgQAV2PK qEgCAAA= 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: 64B657920D.A8EFA X-pwg-MailScanner-From: ipp-bounces@pwg.org Daniel, On Jul 9, 2013, at 2:56 PM, Manchala, Daniel wrote: > Mike, > > I think what Shin is trying to say is that there is an impossibility of a FaxOut Device to detect such things as training failure or lost carrier. I would be incredibly surprised since the standards (and anyone that has used a modem with its speaker turned on) clearly identify ways for both the sender and receiver to detect carrier tones, loss of signal, and so forth. The actual detection mechanism involved on each end naturally varies, as does the reporting capabilities of the hardware, but we should be focused on identifying the events or states and not necessarily the low-level details - for example a "lost carrier" state can be caused by a variety of conditions, but all we care about is that we lost the carrier tone. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Tue Jul 9 14:03:24 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB32A21F9DAC for ; Tue, 9 Jul 2013 14:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDBpezFgOfD1 for ; Tue, 9 Jul 2013 14:03:19 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23B21F9DB5 for ; Tue, 9 Jul 2013 14:03:19 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 58DB27920F; Tue, 9 Jul 2013 17:02:40 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from USA7109MR001.ACS-INC.COM (usa7109mr001.acs-inc.com [63.101.151.9]) by pwg.org (Postfix) with ESMTP id 8F3E07920D for ; Tue, 9 Jul 2013 17:02:15 -0400 (EDT) Received: from usa7109ht002.na.xerox.net ([13.41.230.32]) by USA7109MR001.ACS-INC.COM with ESMTP/TLS/AES128-SHA; 09 Jul 2013 16:02:11 -0500 Received: from USA7109MB013.na.xerox.net ([169.254.5.17]) by USA7109HT002.na.xerox.net ([13.41.230.32]) with mapi id 14.02.0309.002; Tue, 9 Jul 2013 16:02:10 -0500 From: "Manchala, Daniel" To: 'Ira McDonald' Subject: RE: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Topic: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Index: AQHOfLX4q9CUC4v//Ey5LFt95defZZlcsRHVgABrNAD//7U2wA== Date: Tue, 9 Jul 2013 21:02:09 +0000 Message-ID: References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [13.41.230.90] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "'ipp@pwg.org'" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1279436939==" 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: 58DB27920F.A9A7C X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1279436939== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E4503CD23822BF45A1EAEDA0BC5F107404BF20DBusa7109mb013nax_" --_000_E4503CD23822BF45A1EAEDA0BC5F107404BF20DBusa7109mb013nax_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ira, That's right. It seems that some of these alerts maybe used by FaxIn or Fax= Out or both. When we get to writing the FaxIn specification, we would under= stand how the various fax device states (state-reasons) influence or descri= be the alerts. Thanks, Daniel. From: Ira McDonald [mailto:blueroofmusic@gmail.com] Sent: Tuesday, July 09, 2013 1:15 PM To: Manchala, Daniel Cc: Michael Sweet; fx OHTAKE SHIN; ipp@pwg.org Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments Hi Daniel, But the same set of FaxModem subunit alerts (Printer MIB and IPP) MAY be us= ed by either FaxOut or FaxIn or both - implementation choice. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel > wrote: Mike, I think what Shin is trying to say is that there is an impossibility of a F= axOut Device to detect such things as training failure or lost carrier. The= se are generally detected by a receiving facsimile and a sending FaxOut can= at best guess based on timeouts in receiving a response. (Shin, please cla= rify if I understood what you are implying). Daniel. ________________________________________ From: Michael Sweet [msweet@apple.com] Sent: Tuesday, July 09, 2013 8:06 AM To: fx OHTAKE SHIN Cc: Manchala, Daniel; 'ipp@pwg.org' Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments Shin, On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN > wrote: > Hi Mike-san, > > I've returned to my office, so let's discuss again. > My understanding may not be so enough because we've past a week. > > We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3. > Because ITU-T.30 is the reference of FAX protocol, > and in the world, there are too many facsimiles do not control by AT comm= ands. > CUPS is one of many IPP client implementations, also. We want keywords to define not only what is in T.30 but also what is possib= le/feasible to report in generate before, during, and after the fax session= is negotiated. Right now we actually don't report a lot of the state infor= mation shown in the T.30 spec, and clearly some of the MFD Alert fax modem = state keywords are not used by the sender... That said, we haven't made any of the new keywords required to support for = IPP FaxOut. Like all "feature" keywords, the (implied) conditional requirem= ent is that you use a standard keyword if you are reporting what that stand= ard keyword represents, i.e., don't use a vendor keyword if a standard keyw= ord exists. [Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int= /rec/T-REC-T.30-200509-I/en] > > Regards, > Shin > // > --------------------------------------------------------------------- > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > phone: +81-45-755-5474 (direct) > mail: shin.ohtake@fujixerox.co.jp > --------------------------------------------------------------------- > > >> -----Original Message----- >> From: Michael Sweet [mailto:msweet@apple.com] >> Sent: Friday, June 28, 2013 10:22 AM >> To: Manchala, Daniel >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specificat= ion and has comments >> >> Daniel, >> >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" > wrote: >>> I think renaming both 'fax-modem-carrier-lost' and 'fax-modem-training-= failure' to something like >> 'fax-modem-confirmation-not-received' or 'fax-out-modem-confirmation-not= -received' would help. The reasoning is as >> follows: >> >> These names have already been approved (5107.3) and are in use (CUPS, wh= ich provided prototyping specifically for >> the preliminary fax support via efax). >> >> Like I've said on many occasions, we can change the definitions all we l= ike, but unless we want the mess of supporting >> deprecated old names plus semantically identical new names I don't see t= he point in continuing discussion of changing >> the names. >> >> As for fax-in-* and fax-out-*, there are enough common states between re= ceiver and sender that I would not want to >> double things up. >> >> >>> As part of training (speed or data rate such as 9600bps) and at the end= of it, a TCF (Training Check Flag) is sent >> from the fax-out (sending) device to a fax-in (receiving) device. If the= re is a training failure, an FTT (Failure >> to Train) is sent back from the fax-in receiving device to the fax-out s= ending device. If there is no training failure, >> a CFR (Confirmation to Receive) is sent from the fax-in receiving device= to the fax-out sending device. After sufficient >> number of training failures (usually 3), a DCN (Disconnect) signal is se= nt from fax-out device to fax-in device and >> the transmission stops. >>> >>> Likewise, if carrier is lost, there is no response received in terms of= MCF (Message Confirmation) from fax-in device >> at the fax-out device. >>> >>> In either of the two cases, a failure to detect/receive CFR or MCF from= the fax-in device at the fax-out device >> can trigger 'fax-out-modem-confirmation-not-received'. This is how the = sending end will indicate that it lost its >> connection to the receiver. >>> >>> We still could have 'fax-modem-carrier-lost', but on the receiving devi= ce, and probably it is good to rename it >> as 'fax-in-modem-carrier-lost' indicating that this is an error on the f= ax-in device. Likewise, we could have >> 'fax-modem-training-failure' but on the receiving device only and it is = good to rename it (something) as >> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. >>> >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be les= s confusing as to what mode a device is acting >> (as a sender or receiver). >>> >>> Thanks, >>> Daniel. >>> >>> >>> >>> -----Original Message----- >>> From: ipp-bounces@pwg.org [mailto:ipp-bounc= es@pwg.org] On Behalf Of >>> Michael Sweet >>> Sent: Thursday, June 27, 2013 5:07 AM >>> To: fx OHTAKE SHIN >>> Cc: ipp@pwg.org >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut >>> specification and has comments >>> >>> Shin, >>> >>> Thanks for your comments! >>> >>> Responses inline... >>> >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN > wrote: >>>> Greetings, >>>> >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. >>>> >>>> ---- >>>> 8.2 job-state-reasons >>>> 1. fax-modem-carrier-lost >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost >>>> by Called terminal. We think fax-modem-carrier-lost should be removed = from the specification. >>>> If the specification supposes another case, tell us an example on the = facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we lost the con= nection to the receiver. Would changing >> the definition here to something like "Lost connection to the receiver d= uring send." be more descriptive? >>> >>> (in AT command set parlance, this would be a "NO CARRIER" response, >>> received when the connection is lost) >>> >>>> 2. fax-modem-training-failure >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is >>>> detected by Called terminal. We think fax-modem-training-failure shoul= d be removed from the specification. >>>> If the specification supposes another case, tell us an example on the = facsimile protocol sequence. >>> >>> But on the sending end we still need an indication that we were unable = to connect to the receiver after the receiver >> answered the call. This definition has already been updated once, but I = am happy to reword it again to make this clear >> - basically, 'fax-modem-training-failure' means that the receiver answer= ed, the sender got the carrier tone, but the >> sender and receiver were unable to successfully negotiate a data rate. >>> >>> (in AT command set parlance, this is also a "NO CARRIER" response, >>> received after dialing) >>> >>>> 3. fax-modem-voice-detected >>>> If fax-modem-voice-detected specified as a job state, it should >>>> change name to job-calling. Facsimile always detect sound other than >>>> a carrier tone while facsimile dialing numbers to detecting any >>>> facsimile signals, because facsimile may hear ringing tone or machine'= s voice(voice answer system), human's voice(fax >> manual receive). Therefore, fax-modem-voice-detected cannot specify as a= n error job reason, because of ringing tone. >>> >>> I'm not sure I understand your comment, but a couple things: >>> >>> 1. We can't change the names of these keywords: they were defined and >>> approved last year as part of the Printer MIB and IPP MFD Alerts spec >>> (PWG 5107.3-2012). Which of course I don't have referenced and am >>> re-defining the names in the IANA section (editorial changes at >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP >>> registrations] >>> >>> 2. We do want a way to indicate when the receiver answers but does not = respond with a carrier within the connection >> timeout setup in the modem. Again, falling back on the AT command set I = would probably just get a "NO CARRIER" response >> and a hang-up, but some modems did/do report "DELAYED" for the additiona= l rings - we *could* add a keyword for that >> ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this o= ne as-is even if many implementations can't >> support 'fax-modem-voice-detected'. >>> >>> 3. None of these are unconditionally required to implement - certain >>> keywords depend on hardware features that may not be supported by your >>> products, and so naturally you won't report those (similar to how you >>> might not have a duplexing unit in your printer and thus don't have to >>> report or support the "sides" attribute...) >>> >>> _________________________________________________________ >>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>> >>> >>> -- >>> This message has been scanned for viruses and dangerous content by Mail= Scanner, 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 > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --_000_E4503CD23822BF45A1EAEDA0BC5F107404BF20DBusa7109mb013nax_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ira,

 <= /p>

That’s right. It se= ems that some of these alerts maybe used by FaxIn or FaxOut or both. When w= e get to writing the FaxIn specification, we would understand how the various fax device states (state-reasons) influence or describe th= e alerts.

 <= /p>

Thanks,=

Daniel.=

 <= /p>

From: Ira McDo= nald [mailto:blueroofmusic@gmail.com]
Sent: Tuesday, July 09, 2013 1:15 PM
To: Manchala, Daniel
Cc: Michael Sweet; fx OHTAKE SHIN; ipp@pwg.org
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specificat= ion and has comments

 

Hi Daniel,=

But the same set of FaxModem subunit alerts (Printer= MIB and IPP) MAY be used

by either FaxOut or F= axIn or both - implementation choice.

Cheers,

- Ira


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

 

On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel <= ;Daniel.Manc= hala@xerox.com> wrote:

Mike,

I think what Shin is trying to say is that there is an impossibility of a F= axOut Device to detect such things as training failure or lost carrier. The= se are generally detected by a receiving facsimile and a sending FaxOut can= at best guess based on timeouts in receiving a response. (Shin, please clarify if I understood what you ar= e implying).

Daniel.
________________________________________
From: Michael Sweet [msweet@apple.com]
Sent: Tuesday, July 09, 2013 8:06 AM
To: fx OHTAKE SHIN
Cc: Manchala, Daniel; 'ipp@pwg.org'
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments


Shin,

On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.jp> wrote:
> Hi Mike-san,
>
> I've returned to my office, so let's discuss again.
> My understanding may not be so enough because we've past a week.
>
> We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3.
> Because ITU-T.30 is the reference of FAX protocol,
> and in the world, there are too many facsimiles do not control by AT c= ommands.
> CUPS is one of many IPP client implementations, also.

We want keywords to define not only what is in T.30 but also what is possib= le/feasible to report in generate before, during, and after the fax session= is negotiated. Right now we actually don't report a lot of the state infor= mation shown in the T.30 spec, and clearly some of the MFD Alert fax modem state keywords are not used by the= sender...

That said, we haven't made any of the new keywords required to support for = IPP FaxOut. Like all "feature" keywords, the (implied) conditiona= l requirement is that you use a standard keyword if you are reporting what = that standard keyword represents, i.e., don't use a vendor keyword if a standard keyword exists.

[Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int/rec/T-REC-T.30-200509-I/en]


>
> Regards,
> Shin
> //
> ---------------------------------------------------------------------<= br> > Shin Ohtake     CTPF4D, Fuji Xerox Co.,Ltd.
>                phone: +81-45-755-5474 (direct)
>                mail:  shin.ohtake@fujixerox.co.jp=
> ---------------------------------------------------------------------<= br> >
>
>> -----Original Message-----
>> From: Michael Sweet [mailto:ms= weet@apple.com]
>> Sent: Friday, June 28, 2013 10:22 AM
>> To: Manchala, Daniel
>> Cc: fx OHTAKE SHIN; 'ipp@pwg.org'
>> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut spec= ification and has comments
>>
>> Daniel,
>>
>> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" <Daniel.Manchala@xerox.com> wr= ote:
>>> I think renaming both 'fax-modem-carrier-lost' and 'fax-modem-= training-failure' to something like
>> 'fax-modem-confirmation-not-received' or 'fax-out-modem-confirmati= on-not-received' would help. The reasoning is as
>> follows:
>>
>> These names have already been approved (5107.3) and are in use (CU= PS, which provided prototyping specifically for
>> the preliminary fax support via efax).
>>
>> Like I've said on many occasions, we can change the definitions al= l we like, but unless we want the mess of supporting
>> deprecated old names plus semantically identical new names I don't= see the point in continuing discussion of changing
>> the names.
>>
>> As for fax-in-* and fax-out-*, there are enough common states betw= een receiver and sender that I would not want to
>> double things up.
>>
>>
>>> As part of training (speed or data rate such as 9600bps) and a= t the end of it, a TCF (Training Check Flag) is sent
>> from the fax-out (sending) device to a fax-in (receiving) device. = If there is a training failure, an FTT (Failure
>> to Train) is sent back from the fax-in receiving device to the fax= -out sending device. If there is no training failure,
>> a CFR (Confirmation to Receive) is sent from the fax-in receiving = device to the fax-out sending device. After sufficient
>> number of training failures (usually 3), a DCN (Disconnect) signal= is sent from fax-out device to fax-in device and
>> the transmission stops.
>>>
>>> Likewise, if carrier is lost, there is no response received in= terms of MCF (Message Confirmation) from fax-in device
>> at the fax-out device.
>>>
>>> In either of the two cases, a failure to detect/receive CFR or= MCF from the fax-in device at the fax-out device
>> can trigger 'fax-out-modem-confirmation-not-received'.  This = is how the sending end will indicate that it lost its
>> connection to the receiver.
>>>
>>> We still could have 'fax-modem-carrier-lost', but on the recei= ving device, and probably it is good to rename it
>> as 'fax-in-modem-carrier-lost' indicating that this is an error on= the fax-in device. Likewise, we could have
>> 'fax-modem-training-failure' but on the receiving device only and = it is good to rename it (something) as
>> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train.=
>>>
>>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it wou= ld be less confusing as to what mode a device is acting
>> (as a sender or receiver).
>>>
>>> Thanks,
>>> Daniel.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ipp-bounces@pwg.o= rg [mailto:ipp-bounces@pwg.org] On Behalf Of
>>> Michael Sweet
>>> Sent: Thursday, June 27, 2013 5:07 AM
>>> To: fx OHTAKE SHIN
>>> Cc: ipp@pwg.org
>>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut
>>> specification and has comments
>>>
>>> Shin,
>>>
>>> Thanks for your comments!
>>>
>>> Responses inline...
>>>
>>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.jp> wrote:<= br> >>>> Greetings,
>>>>
>>>> Fuji Xerox has comments for the IPP FaxOut specification f= inal call.
>>>>
>>>> ----
>>>> 8.2 job-state-reasons
>>>> 1. fax-modem-carrier-lost
>>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carr= ier is lost
>>>> by Called terminal. We think fax-modem-carrier-lost should= be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we los= t the connection to the receiver.  Would changing
>> the definition here to something like "Lost connection to the= receiver during send." be more descriptive?
>>>
>>> (in AT command set parlance, this would be a "NO CARRIER&= quot; response,
>>> received when the connection is lost)
>>>
>>>> 2. fax-modem-training-failure
>>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training f= ailure is
>>>> detected by Called terminal. We think fax-modem-training-f= ailure should be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we wer= e unable to connect to the receiver after the receiver
>> answered the call. This definition has already been updated once, = but I am happy to reword it again to make this clear
>> - basically, 'fax-modem-training-failure' means that the receiver = answered, the sender got the carrier tone, but the
>> sender and receiver were unable to successfully negotiate a data r= ate.
>>>
>>> (in AT command set parlance, this is also a "NO CARRIER&q= uot; response,
>>> received after dialing)
>>>
>>>> 3. fax-modem-voice-detected
>>>> If fax-modem-voice-detected specified as a job state, it s= hould
>>>> change name to job-calling. Facsimile always detect sound = other than
>>>> a carrier tone while facsimile dialing numbers to detectin= g any
>>>> facsimile signals, because facsimile may hear ringing tone= or machine's voice(voice answer system), human's voice(fax
>> manual receive). Therefore, fax-modem-voice-detected cannot specif= y as an error job reason, because of ringing tone.
>>>
>>> I'm not sure I understand your comment, but a couple things: >>>
>>> 1. We can't change the names of these keywords: they were defi= ned and
>>> approved last year as part of the Printer MIB and IPP MFD Aler= ts spec
>>> (PWG 5107.3-2012). Which of course I don't have referenced and= am
>>> re-defining the names in the IANA section (editorial changes a= t
>>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP
>>> registrations]
>>>
>>> 2. We do want a way to indicate when the receiver answers but = does not respond with a carrier within the connection
>> timeout setup in the modem. Again, falling back on the AT command = set I would probably just get a "NO CARRIER" response
>> and a hang-up, but some modems did/do report "DELAYED" f= or the additional rings - we *could* add a keyword for that
>> ("fax-modem-delayed"? "fax-modem-waiting"?) bu= t I'd like to leave this one as-is even if many implementations can't
>> support 'fax-modem-voice-detected'.
>>>
>>> 3. None of these are unconditionally required to implement - c= ertain
>>> keywords depend on hardware features that may not be supported= by your
>>> products, and so naturally you won't report those (similar to = how you
>>> might not have a duplexing unit in your printer and thus don't= have to
>>> report or support the "sides" attribute...)
>>>
>>> _________________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>
>>>
>>> --
>>> This message has been scanned for viruses and dangerous conten= t 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
>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


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

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

 


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --_000_E4503CD23822BF45A1EAEDA0BC5F107404BF20DBusa7109mb013nax_-- --===============1279436939== 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 --===============1279436939==-- From ipp-bounces@pwg.org Tue Jul 9 14:16:24 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF2D21F963F for ; Tue, 9 Jul 2013 14:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsxFS2D77Rid for ; Tue, 9 Jul 2013 14:16:19 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0BF21F9808 for ; Tue, 9 Jul 2013 14:16:19 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 7A81279217; Tue, 9 Jul 2013 17:15:40 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by pwg.org (Postfix) with ESMTP id 845A0791F2 for ; Tue, 9 Jul 2013 17:15:17 -0400 (EDT) Received: by mail-ie0-f174.google.com with SMTP id 9so13759400iec.33 for ; Tue, 09 Jul 2013 14:15:16 -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=ED0Cbvm4WCqXTRz/EiU4ZlQZXcZ053Zf5/LF2HUDXrA=; b=XPAaj1jdRzSftwj5dvzUKBWyIsyVnzeou+Nbv+T92wDrwCYRlL8EQe3AFY6vqAIVU0 V0+YRiKaCVsJIM730U4RrcHTAe+S4HqcAQU/lLf48+0QBi1phOifc6tQt3AJuFVMFLA6 N4mxOUwK7O89k+HCTO/qr7Gj2KKMuRb6BzM96k57xAZaCE0B08A8k2oZvVRbYw4YKROu 8ZOw5TmRNvSuD/yx/7tp8kCxfiFq2O6tzeN5bLV/uizC7eIUhQAPW71tclkEQLF/DMWW +fn6DNsQJysgvY8goa7CVXDCw8m7K7r3rfuvoHNW3de7ZMEeNeKuymje3zJSs+4rNU0D zSfg== MIME-Version: 1.0 X-Received: by 10.42.224.72 with SMTP id in8mr6864538icb.114.1373404516699; Tue, 09 Jul 2013 14:15:16 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Tue, 9 Jul 2013 14:15:16 -0700 (PDT) In-Reply-To: References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net> Date: Tue, 9 Jul 2013 17:15:16 -0400 Message-ID: Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments From: Ira McDonald To: "Manchala, Daniel" 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="===============0302455496==" 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: 7A81279217.A9C18 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0302455496== Content-Type: multipart/alternative; boundary=001a11331f2659da2b04e11aa8af --001a11331f2659da2b04e11aa8af Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, Bear in mind that PWG SM FaxIn spec already *has* been written (and reviewed several times). And no - none of the PWG SM specs say anything details of Subunit alerts or states. That is strictly in the MFD Common Model - becoming SM 2.0 Model. Services use Subunits but do NOT define their semantics. The Printer MIB v2 (RFC 3805) authoritatively defines the Subunit states. The list of FaxModem alerts in PWG 5107.3 was extensively reviewed and discussed for over two years before publication - I took them originally from the IETF Modem MIB (RFC 1696) and added several based on suggestions from MFP vendors who were active PWG members. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Jul 9, 2013 at 5:02 PM, Manchala, Daniel wrote: > Ira,**** > > ** ** > > That=92s right. It seems that some of these alerts maybe used by FaxIn or > FaxOut or both. When we get to writing the FaxIn specification, we would > understand how the various fax device states (state-reasons) influence or > describe the alerts.**** > > ** ** > > Thanks,**** > > Daniel.**** > > ** ** > > *From:* Ira McDonald [mailto:blueroofmusic@gmail.com] > *Sent:* Tuesday, July 09, 2013 1:15 PM > *To:* Manchala, Daniel > *Cc:* Michael Sweet; fx OHTAKE SHIN; ipp@pwg.org > > *Subject:* Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification > and has comments**** > > ** ** > > Hi Daniel,**** > > But the same set of FaxModem subunit alerts (Printer MIB and IPP) MAY be > used**** > > by either FaxOut or FaxIn or both - implementation choice.**** > > Cheers,**** > > - Ira**** > > > **** > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434**** > > ** ** > > On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel < > Daniel.Manchala@xerox.com> wrote:**** > > Mike, > > I think what Shin is trying to say is that there is an impossibility of a > FaxOut Device to detect such things as training failure or lost carrier. > These are generally detected by a receiving facsimile and a sending FaxOut > can at best guess based on timeouts in receiving a response. (Shin, please > clarify if I understood what you are implying). > > Daniel. > ________________________________________ > From: Michael Sweet [msweet@apple.com] > Sent: Tuesday, July 09, 2013 8:06 AM > To: fx OHTAKE SHIN > Cc: Manchala, Daniel; 'ipp@pwg.org' > Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification > and has comments**** > > > Shin, > > On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN > wrote: > > Hi Mike-san, > > > > I've returned to my office, so let's discuss again. > > My understanding may not be so enough because we've past a week. > > > > We should discus with ITU-T.30 recommendations(facsimile protocols), > > instead of AT commands or PWG 5107.3. > > Because ITU-T.30 is the reference of FAX protocol, > > and in the world, there are too many facsimiles do not control by AT > commands. > > CUPS is one of many IPP client implementations, also. > > We want keywords to define not only what is in T.30 but also what is > possible/feasible to report in generate before, during, and after the fax > session is negotiated. Right now we actually don't report a lot of the > state information shown in the T.30 spec, and clearly some of the MFD Ale= rt > fax modem state keywords are not used by the sender... > > That said, we haven't made any of the new keywords required to support for > IPP FaxOut. Like all "feature" keywords, the (implied) conditional > requirement is that you use a standard keyword if you are reporting what > that standard keyword represents, i.e., don't use a vendor keyword if a > standard keyword exists. > > [Note for myself; Add normative reference to ITU-T.30 at > http://www.itu.int/rec/T-REC-T.30-200509-I/en] > > > > > > Regards, > > Shin > > // > > --------------------------------------------------------------------- > > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > > phone: +81-45-755-5474 (direct) > > mail: shin.ohtake@fujixerox.co.jp > > --------------------------------------------------------------------- > > > > > >> -----Original Message----- > >> From: Michael Sweet [mailto:msweet@apple.com] > >> Sent: Friday, June 28, 2013 10:22 AM > >> To: Manchala, Daniel > >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' > >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > specification and has comments > >> > >> Daniel, > >> > >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" < > Daniel.Manchala@xerox.com> wrote: > >>> I think renaming both 'fax-modem-carrier-lost' and > 'fax-modem-training-failure' to something like > >> 'fax-modem-confirmation-not-received' or > 'fax-out-modem-confirmation-not-received' would help. The reasoning is as > >> follows: > >> > >> These names have already been approved (5107.3) and are in use (CUPS, > which provided prototyping specifically for > >> the preliminary fax support via efax). > >> > >> Like I've said on many occasions, we can change the definitions all we > like, but unless we want the mess of supporting > >> deprecated old names plus semantically identical new names I don't see > the point in continuing discussion of changing > >> the names. > >> > >> As for fax-in-* and fax-out-*, there are enough common states between > receiver and sender that I would not want to > >> double things up. > >> > >> > >>> As part of training (speed or data rate such as 9600bps) and at the > end of it, a TCF (Training Check Flag) is sent > >> from the fax-out (sending) device to a fax-in (receiving) device. If > there is a training failure, an FTT (Failure > >> to Train) is sent back from the fax-in receiving device to the fax-out > sending device. If there is no training failure, > >> a CFR (Confirmation to Receive) is sent from the fax-in receiving > device to the fax-out sending device. After sufficient > >> number of training failures (usually 3), a DCN (Disconnect) signal is > sent from fax-out device to fax-in device and > >> the transmission stops. > >>> > >>> Likewise, if carrier is lost, there is no response received in terms > of MCF (Message Confirmation) from fax-in device > >> at the fax-out device. > >>> > >>> In either of the two cases, a failure to detect/receive CFR or MCF > from the fax-in device at the fax-out device > >> can trigger 'fax-out-modem-confirmation-not-received'. This is how the > sending end will indicate that it lost its > >> connection to the receiver. > >>> > >>> We still could have 'fax-modem-carrier-lost', but on the receiving > device, and probably it is good to rename it > >> as 'fax-in-modem-carrier-lost' indicating that this is an error on the > fax-in device. Likewise, we could have > >> 'fax-modem-training-failure' but on the receiving device only and it is > good to rename it (something) as > >> 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. > >>> > >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be > less confusing as to what mode a device is acting > >> (as a sender or receiver). > >>> > >>> Thanks, > >>> Daniel. > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of > >>> Michael Sweet > >>> Sent: Thursday, June 27, 2013 5:07 AM > >>> To: fx OHTAKE SHIN > >>> Cc: ipp@pwg.org > >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > >>> specification and has comments > >>> > >>> Shin, > >>> > >>> Thanks for your comments! > >>> > >>> Responses inline... > >>> > >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN < > shin.ohtake@fujixerox.co.jp> wrote: > >>>> Greetings, > >>>> > >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. > >>>> > >>>> ---- > >>>> 8.2 job-state-reasons > >>>> 1. fax-modem-carrier-lost > >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is lost > >>>> by Called terminal. We think fax-modem-carrier-lost should be removed > from the specification. > >>>> If the specification supposes another case, tell us an example on the > facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we lost the > connection to the receiver. Would changing > >> the definition here to something like "Lost connection to the receiver > during send." be more descriptive? > >>> > >>> (in AT command set parlance, this would be a "NO CARRIER" response, > >>> received when the connection is lost) > >>> > >>>> 2. fax-modem-training-failure > >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is > >>>> detected by Called terminal. We think fax-modem-training-failure > should be removed from the specification. > >>>> If the specification supposes another case, tell us an example on the > facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we were unable > to connect to the receiver after the receiver > >> answered the call. This definition has already been updated once, but I > am happy to reword it again to make this clear > >> - basically, 'fax-modem-training-failure' means that the receiver > answered, the sender got the carrier tone, but the > >> sender and receiver were unable to successfully negotiate a data rate. > >>> > >>> (in AT command set parlance, this is also a "NO CARRIER" response, > >>> received after dialing) > >>> > >>>> 3. fax-modem-voice-detected > >>>> If fax-modem-voice-detected specified as a job state, it should > >>>> change name to job-calling. Facsimile always detect sound other than > >>>> a carrier tone while facsimile dialing numbers to detecting any > >>>> facsimile signals, because facsimile may hear ringing tone or > machine's voice(voice answer system), human's voice(fax > >> manual receive). Therefore, fax-modem-voice-detected cannot specify as > an error job reason, because of ringing tone. > >>> > >>> I'm not sure I understand your comment, but a couple things: > >>> > >>> 1. We can't change the names of these keywords: they were defined and > >>> approved last year as part of the Printer MIB and IPP MFD Alerts spec > >>> (PWG 5107.3-2012). Which of course I don't have referenced and am > >>> re-defining the names in the IANA section (editorial changes at > >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP > >>> registrations] > >>> > >>> 2. We do want a way to indicate when the receiver answers but does not > respond with a carrier within the connection > >> timeout setup in the modem. Again, falling back on the AT command set I > would probably just get a "NO CARRIER" response > >> and a hang-up, but some modems did/do report "DELAYED" for the > additional rings - we *could* add a keyword for that > >> ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this > one as-is even if many implementations can't > >> support 'fax-modem-voice-detected'. > >>> > >>> 3. None of these are unconditionally required to implement - certain > >>> keywords depend on hardware features that may not be supported by your > >>> products, and so naturally you won't report those (similar to how you > >>> might not have a duplexing unit in your printer and thus don't have to > >>> report or support the "sides" attribute...) > >>> > >>> _________________________________________________________ > >>> 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 > > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp**** > > ** ** > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --001a11331f2659da2b04e11aa8af Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Bear in mind that P= WG SM FaxIn spec already *has* been written (and reviewed several times).
And no - none of the PWG SM <service> specs say anything = details of Subunit alerts or states.

That is strictly in the MFD Common Model - becoming SM 2.0 M= odel.=A0 Services use Subunits
but do NOT define their semant= ics.=A0 The Printer MIB v2 (RFC 3805) authoritatively defines the
Subuni= t states.

The list of FaxModem alerts in PWG 5107.3 was extensively re= viewed and discussed for over
two years before publication - I took them= originally from the IETF Modem MIB (RFC 1696) and
added seve= ral based on suggestions from MFP vendors who were active PWG members.

Cheers,
- Ira



Ira McDonald (Musician = / Software Architect)
Chair - Linux Foundation Open Printing WG
Secre= tary - IEEE-ISTO Printer 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



On Tue, Jul 9, 2013 at 5:02 PM, Manchala= , Daniel <Daniel.Manchala@xerox.com> wrote:

Ira,=

=A0<= /p>

That=92s right. It seems = that some of these alerts maybe used by FaxIn or FaxOut or both. When we ge= t to writing the FaxIn specification, we would understand how the various fax device states (state-reasons) influence or describe th= e alerts.

=A0<= /p>

Thanks,

Daniel.

=A0<= /p>

From: Ira McDo= nald [mailto:b= lueroofmusic@gmail.com]
Sent: Tuesday, July 09, 2013 1:15 PM
To: Manchala, Daniel
Cc: Michael Sweet; fx OHTAKE SHIN; ipp@pwg.org


Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specificat= ion and has comments

=A0

Hi Daniel,<= /u>

But the same set of FaxModem subunit alerts (Printer= MIB and IPP) MAY be used

by either FaxOut or F= axIn or both - implementation choice.

Cheers,

- Ira


Ira McDonald (Musicia= n / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc=
mailto:blueroo= fmusic@gmail.com
Winter=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=

=A0

On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel <= ;Daniel.Manc= hala@xerox.com> wrote:

Mike,

I think what Shin is trying to say is that there is an impossibility of a F= axOut Device to detect such things as training failure or lost carrier. The= se are generally detected by a receiving facsimile and a sending FaxOut can= at best guess based on timeouts in receiving a response. (Shin, please clarify if I understood what you ar= e implying).

Daniel.
________________________________________
From: Michael Sweet [= msweet@apple.com]
Sent: Tuesday, July 09, 2013 8:06 AM
To: fx OHTAKE SHIN
Cc: Manchala, Daniel; 'ipp@pwg.org'
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and= has comments


Shin,

On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.jp> wro= te:
> Hi Mike-san,
>
> I've returned to my office, so let's discuss again.
> My understanding may not be so enough because we've past a week. >
> We should discus with ITU-T.30 recommendations(facsimile protocols), > instead of AT commands or PWG 5107.3.
> Because ITU-T.30 is the reference of FAX protocol,
> and in the world, there are too many facsimiles do not control by AT c= ommands.
> CUPS is one of many IPP client implementations, also.

We want keywords to define not only what is in T.30 but also what is possib= le/feasible to report in generate before, during, and after the fax session= is negotiated. Right now we actually don't report a lot of the state i= nformation shown in the T.30 spec, and clearly some of the MFD Alert fax modem state keywords are not used by the= sender...

That said, we haven't made any of the new keywords required to support = for IPP FaxOut. Like all "feature" keywords, the (implied) condit= ional requirement is that you use a standard keyword if you are reporting w= hat that standard keyword represents, i.e., don't use a vendor keyword if a standard keyword exists.

[Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int/rec/T-REC-T.30-200509-I/en]


>
> Regards,
> Shin
> //
> ---------------------------------------------------------------------<= br> > Shin Ohtake =A0 =A0 CTPF4D, Fuji Xerox Co.,Ltd.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +81-45-755-5474 (direct)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mail: =A0shin.ohtake@fujixerox.co.jp
> ---------------------------------------------------------------------<= br> >
>
>> -----Original Message-----
>> From: Michael Sweet [mailto:msweet@apple.com]
>> Sent: Friday, June 28, 2013 10:22 AM
>> To: Manchala, Daniel
>> Cc: fx OHTAKE SHIN; 'ipp@pwg.org'
>> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut spec= ification and has comments
>>
>> Daniel,
>>
>> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" <Daniel.Manchala@xe= rox.com> wrote:
>>> I think renaming both 'fax-modem-carrier-lost' and = 9;fax-modem-training-failure' to something like
>> 'fax-modem-confirmation-not-received' or 'fax-out-mode= m-confirmation-not-received' would help. The reasoning is as
>> follows:
>>
>> These names have already been approved (5107.3) and are in use (CU= PS, which provided prototyping specifically for
>> the preliminary fax support via efax).
>>
>> Like I've said on many occasions, we can change the definition= s all we like, but unless we want the mess of supporting
>> deprecated old names plus semantically identical new names I don&#= 39;t see the point in continuing discussion of changing
>> the names.
>>
>> As for fax-in-* and fax-out-*, there are enough common states betw= een receiver and sender that I would not want to
>> double things up.
>>
>>
>>> As part of training (speed or data rate such as 9600bps) and a= t the end of it, a TCF (Training Check Flag) is sent
>> from the fax-out (sending) device to a fax-in (receiving) device. = If there is a training failure, an FTT (Failure
>> to Train) is sent back from the fax-in receiving device to the fax= -out sending device. If there is no training failure,
>> a CFR (Confirmation to Receive) is sent from the fax-in receiving = device to the fax-out sending device. After sufficient
>> number of training failures (usually 3), a DCN (Disconnect) signal= is sent from fax-out device to fax-in device and
>> the transmission stops.
>>>
>>> Likewise, if carrier is lost, there is no response received in= terms of MCF (Message Confirmation) from fax-in device
>> at the fax-out device.
>>>
>>> In either of the two cases, a failure to detect/receive CFR or= MCF from the fax-in device at the fax-out device
>> can trigger 'fax-out-modem-confirmation-not-received'. =A0= This is how the sending end will indicate that it lost its
>> connection to the receiver.
>>>
>>> We still could have 'fax-modem-carrier-lost', but on t= he receiving device, and probably it is good to rename it
>> as 'fax-in-modem-carrier-lost' indicating that this is an = error on the fax-in device. Likewise, we could have
>> 'fax-modem-training-failure' but on the receiving device o= nly and it is good to rename it (something) as
>> 'fax-in-modem-training-failure' or 'fax-in-modem-failu= re-to-train.
>>>
>>> I like to have the 'fax-out-*' and 'fax-in-*' = syntax as it would be less confusing as to what mode a device is acting
>> (as a sender or receiver).
>>>
>>> Thanks,
>>> Daniel.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of
>>> Michael Sweet
>>> Sent: Thursday, June 27, 2013 5:07 AM
>>> To: fx OHTAKE SHIN
>>> Cc: ipp@pwg.o= rg
>>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut
>>> specification and has comments
>>>
>>> Shin,
>>>
>>> Thanks for your comments!
>>>
>>> Responses inline...
>>>
>>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN <shin.ohtake@fujixerox.co.= jp> wrote:
>>>> Greetings,
>>>>
>>>> Fuji Xerox has comments for the IPP FaxOut specification f= inal call.
>>>>
>>>> ----
>>>> 8.2 job-state-reasons
>>>> 1. fax-modem-carrier-lost
>>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carr= ier is lost
>>>> by Called terminal. We think fax-modem-carrier-lost should= be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we los= t the connection to the receiver. =A0Would changing
>> the definition here to something like "Lost connection to the= receiver during send." be more descriptive?
>>>
>>> (in AT command set parlance, this would be a "NO CARRIER&= quot; response,
>>> received when the connection is lost)
>>>
>>>> 2. fax-modem-training-failure
>>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training f= ailure is
>>>> detected by Called terminal. We think fax-modem-training-f= ailure should be removed from the specification.
>>>> If the specification supposes another case, tell us an exa= mple on the facsimile protocol sequence.
>>>
>>> But on the sending end we still need an indication that we wer= e unable to connect to the receiver after the receiver
>> answered the call. This definition has already been updated once, = but I am happy to reword it again to make this clear
>> - basically, 'fax-modem-training-failure' means that the r= eceiver answered, the sender got the carrier tone, but the
>> sender and receiver were unable to successfully negotiate a data r= ate.
>>>
>>> (in AT command set parlance, this is also a "NO CARRIER&q= uot; response,
>>> received after dialing)
>>>
>>>> 3. fax-modem-voice-detected
>>>> If fax-modem-voice-detected specified as a job state, it s= hould
>>>> change name to job-calling. Facsimile always detect sound = other than
>>>> a carrier tone while facsimile dialing numbers to detectin= g any
>>>> facsimile signals, because facsimile may hear ringing tone= or machine's voice(voice answer system), human's voice(fax
>> manual receive). Therefore, fax-modem-voice-detected cannot specif= y as an error job reason, because of ringing tone.
>>>
>>> I'm not sure I understand your comment, but a couple thing= s:
>>>
>>> 1. We can't change the names of these keywords: they were = defined and
>>> approved last year as part of the Printer MIB and IPP MFD Aler= ts spec
>>> (PWG 5107.3-2012). Which of course I don't have referenced= and am
>>> re-defining the names in the IANA section (editorial changes a= t
>>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP
>>> registrations]
>>>
>>> 2. We do want a way to indicate when the receiver answers but = does not respond with a carrier within the connection
>> timeout setup in the modem. Again, falling back on the AT command = set I would probably just get a "NO CARRIER" response
>> and a hang-up, but some modems did/do report "DELAYED" f= or the additional rings - we *could* add a keyword for that
>> ("fax-modem-delayed"? "fax-modem-waiting"?) bu= t I'd like to leave this one as-is even if many implementations can'= ;t
>> support 'fax-modem-voice-detected'.
>>>
>>> 3. None of these are unconditionally required to implement - c= ertain
>>> keywords depend on hardware features that may not be supported= by your
>>> products, and so naturally you won't report those (similar= to how you
>>> might not have a duplexing unit in your printer and thus don&#= 39;t have to
>>> report or support the "sides" attribute...)
>>>
>>> _________________________________________________________
>>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>
>>>
>>> --
>>> This message has been scanned for viruses and dangerous conten= t 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
>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


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

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

=A0



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --001a11331f2659da2b04e11aa8af-- --===============0302455496== 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 --===============0302455496==-- From ipp-bounces@pwg.org Wed Jul 10 01:43:43 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568FC21F9FC1 for ; Wed, 10 Jul 2013 01:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_55=0.6] 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 tIoU7efJRRzB for ; Wed, 10 Jul 2013 01:43:37 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE221F9F52 for ; Wed, 10 Jul 2013 01:43:37 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 018927921B; Wed, 10 Jul 2013 04:43:11 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mo.mxl.2iij.net (mo1500.mxl.2iij.net [203.180.99.16]) by pwg.org (Postfix) with ESMTP id 6D9A079216 for ; Wed, 10 Jul 2013 04:42:46 -0400 (EDT) Received: by mo.mxl.2iij.net (mxl-mo1500) id r6A8ghSc020417; Wed, 10 Jul 2013 17:42:43 +0900 Received: from unknown [210.173.21.247] (EHLO mx03.fujixerox.co.jp) by mas1505a.mxl.2iij.net(mxl_mta-6.15.0-6) over TLS secured channel with ESMTP id 38e1dd15.0.271489.00-2324.486254.mas1505a.mxl.2iij.net (envelope-from ); Wed, 10 Jul 2013 17:42:43 +0900 (JST) X-MXL-Hash: 51dd1e83308ce268-05b63fa009bb8fd6a86c8f7e81e4b1461f8d064b Received: from ma11.fujixerox.co.jp ([143.94.100.182]) by mx03.fujixerox.co.jp with ESMTP id r6A8gh7O018320; Wed, 10 Jul 2013 17:42:43 +0900 Received: from ma11.fujixerox.co.jp (root@localhost) by ma11.fujixerox.co.jp with ESMTP id r6A8ggvA015564; Wed, 10 Jul 2013 17:42:42 +0900 Received: from unknown [143.94.100.180] by ma11.fujixerox.co.jp with ESMTP id TAA15563; Wed, 10 Jul 2013 17:42:42 +0900 Received: from exg01.kdc.fujixerox.co.jp ([143.94.250.50]) by ms2.dc.fxis.co.jp (8.13.8/8.13.8) with ESMTP id r6A8ggEt010587; Wed, 10 Jul 2013 17:42:42 +0900 (JST) Received: from FX-JPN-EXMBV03.dc00.fujixerox.net ([143.94.250.54]) by fx-jpn-exhcs01.dc00.fujixerox.net ([143.94.250.50]) with mapi; Wed, 10 Jul 2013 17:42:42 +0900 From: fx OHTAKE SHIN To: "Manchala, Daniel" , Michael Sweet Date: Wed, 10 Jul 2013 17:42:51 +0900 Subject: RE: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Topic: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments Thread-Index: AQHOfLX4q9CUC4v//Ey5LFt95defZZlcsRHVgADk9CA= Message-ID: <101E5D20AB29744AB6F7A3E58EBC916571AC25CC55@FX-JPN-EXMBV03.dc00.fujixerox.net> References: <101E5D20AB29744AB6F7A3E58EBC916571AC1CAA0B@FX-JPN-EXMBV03.dc00.fujixerox.net> <101E5D20AB29744AB6F7A3E58EBC916571AC25CA55@FX-JPN-EXMBV03.dc00.fujixerox.net>, In-Reply-To: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 X-Spam: exempt X-MAIL-FROM: X-SOURCE-IP: [210.173.21.247] 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="===============1591068235==" 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: 018927921B.AA493 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1591068235== Content-Language: ja-JP Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010A_01CE7D94.E674A900" ------=_NextPart_000_010A_01CE7D94.E674A900 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Thank you Daniel-san, > I think what Shin is trying to say is that there is an impossibility of a FaxOut Device to detect such things as training > failure or lost carrier. Your comments is just my idea. Fax Devices have some know/how methods to detect FAX protocol error with ITU-T.30 protocol, telephone line status, and so on, they are implementation arts, so we should discuss FaxOut specification based on the FAX standard. Regards, Shin // --------------------------------------------------------------------- Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. phone: +81-45-755-5474 (direct) mail: shin.ohtake@fujixerox.co.jp --------------------------------------------------------------------- > -----Original Message----- > From: Manchala, Daniel [mailto:Daniel.Manchala@xerox.com] > Sent: Wednesday, July 10, 2013 3:57 AM > To: Michael Sweet; fx OHTAKE SHIN > Cc: 'ipp@pwg.org' > Subject: RE: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments > > Mike, > > I think what Shin is trying to say is that there is an impossibility of a FaxOut Device to detect such things as training > failure or lost carrier. These are generally detected by a receiving facsimile and a sending FaxOut can at best guess > based on timeouts in receiving a response. (Shin, please clarify if I understood what you are implying). > > Daniel. > ________________________________________ > From: Michael Sweet [msweet@apple.com] > Sent: Tuesday, July 09, 2013 8:06 AM > To: fx OHTAKE SHIN > Cc: Manchala, Daniel; 'ipp@pwg.org' > Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments > > Shin, > > On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN wrote: > > Hi Mike-san, > > > > I've returned to my office, so let's discuss again. > > My understanding may not be so enough because we've past a week. > > > > We should discus with ITU-T.30 recommendations(facsimile protocols), > > instead of AT commands or PWG 5107.3. > > Because ITU-T.30 is the reference of FAX protocol, and in the world, > > there are too many facsimiles do not control by AT commands. > > CUPS is one of many IPP client implementations, also. > > We want keywords to define not only what is in T.30 but also what is possible/feasible to report in generate before, > during, and after the fax session is negotiated. Right now we actually don't report a lot of the state information > shown in the T.30 spec, and clearly some of the MFD Alert fax modem state keywords are not used by the sender... > > That said, we haven't made any of the new keywords required to support for IPP FaxOut. Like all "feature" keywords, > the (implied) conditional requirement is that you use a standard keyword if you are reporting what that standard keyword > represents, i.e., don't use a vendor keyword if a standard keyword exists. > > [Note for myself; Add normative reference to ITU-T.30 at http://www.itu.int/rec/T-REC-T.30-200509-I/en] > > > > > > Regards, > > Shin > > // > > --------------------------------------------------------------------- > > Shin Ohtake CTPF4D, Fuji Xerox Co.,Ltd. > > phone: +81-45-755-5474 (direct) > > mail: shin.ohtake@fujixerox.co.jp > > --------------------------------------------------------------------- > > > > > >> -----Original Message----- > >> From: Michael Sweet [mailto:msweet@apple.com] > >> Sent: Friday, June 28, 2013 10:22 AM > >> To: Manchala, Daniel > >> Cc: fx OHTAKE SHIN; 'ipp@pwg.org' > >> Subject: Re: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > >> specification and has comments > >> > >> Daniel, > >> > >> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" wrote: > >>> I think renaming both 'fax-modem-carrier-lost' and > >>> 'fax-modem-training-failure' to something like > >> 'fax-modem-confirmation-not-received' or > >> 'fax-out-modem-confirmation-not-received' would help. The reasoning > >> is as > >> follows: > >> > >> These names have already been approved (5107.3) and are in use (CUPS, > >> which provided prototyping specifically for the preliminary fax support via efax). > >> > >> Like I've said on many occasions, we can change the definitions all > >> we like, but unless we want the mess of supporting deprecated old > >> names plus semantically identical new names I don't see the point in continuing discussion of changing the names. > >> > >> As for fax-in-* and fax-out-*, there are enough common states between > >> receiver and sender that I would not want to double things up. > >> > >> > >>> As part of training (speed or data rate such as 9600bps) and at the > >>> end of it, a TCF (Training Check Flag) is sent > >> from the fax-out (sending) device to a fax-in (receiving) device. If > >> there is a training failure, an FTT (Failure to Train) is sent back > >> from the fax-in receiving device to the fax-out sending device. If > >> there is no training failure, a CFR (Confirmation to Receive) is sent > >> from the fax-in receiving device to the fax-out sending device. After sufficient number of training failures (usually > 3), a DCN (Disconnect) signal is sent from fax-out device to fax-in device and the transmission stops. > >>> > >>> Likewise, if carrier is lost, there is no response received in terms > >>> of MCF (Message Confirmation) from fax-in device > >> at the fax-out device. > >>> > >>> In either of the two cases, a failure to detect/receive CFR or MCF > >>> from the fax-in device at the fax-out device > >> can trigger 'fax-out-modem-confirmation-not-received'. This is how > >> the sending end will indicate that it lost its connection to the receiver. > >>> > >>> We still could have 'fax-modem-carrier-lost', but on the receiving > >>> device, and probably it is good to rename it > >> as 'fax-in-modem-carrier-lost' indicating that this is an error on > >> the fax-in device. Likewise, we could have > >> 'fax-modem-training-failure' but on the receiving device only and it is good to rename it (something) as > 'fax-in-modem-training-failure' or 'fax-in-modem-failure-to-train. > >>> > >>> I like to have the 'fax-out-*' and 'fax-in-*' syntax as it would be > >>> less confusing as to what mode a device is acting > >> (as a sender or receiver). > >>> > >>> Thanks, > >>> Daniel. > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: ipp-bounces@pwg.org [mailto:ipp-bounces@pwg.org] On Behalf Of > >>> Michael Sweet > >>> Sent: Thursday, June 27, 2013 5:07 AM > >>> To: fx OHTAKE SHIN > >>> Cc: ipp@pwg.org > >>> Subject: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut > >>> specification and has comments > >>> > >>> Shin, > >>> > >>> Thanks for your comments! > >>> > >>> Responses inline... > >>> > >>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN wrote: > >>>> Greetings, > >>>> > >>>> Fuji Xerox has comments for the IPP FaxOut specification final call. > >>>> > >>>> ---- > >>>> 8.2 job-state-reasons > >>>> 1. fax-modem-carrier-lost > >>>> See ITU-T T.30(09/2005)- Annex A Examples 13, FAX MSG carrier is > >>>> lost by Called terminal. We think fax-modem-carrier-lost should be removed from the specification. > >>>> If the specification supposes another case, tell us an example on the facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we lost the > >>> connection to the receiver. Would changing > >> the definition here to something like "Lost connection to the receiver during send." be more descriptive? > >>> > >>> (in AT command set parlance, this would be a "NO CARRIER" response, > >>> received when the connection is lost) > >>> > >>>> 2. fax-modem-training-failure > >>>> See ITU-T T.30(09/2005)-Appendix IV Examples 4, Training failure is > >>>> detected by Called terminal. We think fax-modem-training-failure should be removed from the specification. > >>>> If the specification supposes another case, tell us an example on the facsimile protocol sequence. > >>> > >>> But on the sending end we still need an indication that we were > >>> unable to connect to the receiver after the receiver > >> answered the call. This definition has already been updated once, but > >> I am happy to reword it again to make this clear > >> - basically, 'fax-modem-training-failure' means that the receiver > >> answered, the sender got the carrier tone, but the sender and receiver were unable to successfully negotiate a > data rate. > >>> > >>> (in AT command set parlance, this is also a "NO CARRIER" response, > >>> received after dialing) > >>> > >>>> 3. fax-modem-voice-detected > >>>> If fax-modem-voice-detected specified as a job state, it should > >>>> change name to job-calling. Facsimile always detect sound other > >>>> than a carrier tone while facsimile dialing numbers to detecting > >>>> any facsimile signals, because facsimile may hear ringing tone or > >>>> machine's voice(voice answer system), human's voice(fax > >> manual receive). Therefore, fax-modem-voice-detected cannot specify as an error job reason, because of ringing > tone. > >>> > >>> I'm not sure I understand your comment, but a couple things: > >>> > >>> 1. We can't change the names of these keywords: they were defined > >>> and approved last year as part of the Printer MIB and IPP MFD Alerts > >>> spec (PWG 5107.3-2012). Which of course I don't have referenced and > >>> am re-defining the names in the IANA section (editorial changes at > >>> least...) [NOTE TO SELF: Add 5107.3 IANA definitions to IPP > >>> registrations] > >>> > >>> 2. We do want a way to indicate when the receiver answers but does > >>> not respond with a carrier within the connection > >> timeout setup in the modem. Again, falling back on the AT command set > >> I would probably just get a "NO CARRIER" response and a hang-up, but > >> some modems did/do report "DELAYED" for the additional rings - we > >> *could* add a keyword for that ("fax-modem-delayed"? "fax-modem-waiting"?) but I'd like to leave this one as-is > even if many implementations can't support 'fax-modem-voice-detected'. > >>> > >>> 3. None of these are unconditionally required to implement - certain > >>> keywords depend on hardware features that may not be supported by > >>> your products, and so naturally you won't report those (similar to > >>> how you might not have a duplexing unit in your printer and thus > >>> don't have to report or support the "sides" attribute...) > >>> > >>> _________________________________________________________ > >>> 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 > > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair ------=_NextPart_000_010A_01CE7D94.E674A900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIPQzCCA1owggJCoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwUDELMAkG A1UEBhMCSlAxGDAWBgNVBAoTD1NFQ09NIFRydXN0Lm5ldDEnMCUGA1UECxMe U2VjdXJpdHkgQ29tbXVuaWNhdGlvbiBSb290Q0ExMB4XDTAzMDkzMDA0MjA0 OVoXDTIzMDkzMDA0MjA0OVowUDELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD1NF Q09NIFRydXN0Lm5ldDEnMCUGA1UECxMeU2VjdXJpdHkgQ29tbXVuaWNhdGlv biBSb290Q0ExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs7P+ f9Ntse8WfFelDG12ii9Lv2T7TO6K8PMpfPX/7irg6em6W2QimppvLDomaVEF mSbc1RxqccaafR6d3XxsxoxnZ0o++HGwGSepCQymlb9LjAz6VZg72OgioUtx OHmsl5Jps4l+6iFoBpgUlofSYTa8bSdWnlfuwMBW/TLPpNmOwiPXjajz2CWs l+RwOPS2OrSdO5cmQ6OhvElZckwjMIcBWPZOvhxoVmavzUFdyLNNKlVGqx/a HuJAPdvNfbmSgJw33QyWZJ3cIvdki99h3hWUUhWgfVLJS6ghycax7cvDlWDR D/CrcPjfy01+7Nb6q9m9f1Typel5+tnWdiQocwIDAQABoz8wPTAdBgNVHQ4E FgQUoHNJmWjchVtl45soL1efvTO8B0gwCwYDVR0PBAQDAgEGMA8GA1UdEwEB /wQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAGhAqai75E9debMFtRezYBPr xpJd4NHTav77vpttv8cFbVkgxBzwt9qEWAJj+kgW70+lC/dKmPI/nhutR2tj zghH61I/eJyvTa741U/PmpgqEEE5UsTd2ZsO75MBrrIuymhCJEJssLM6Ps3p 2kjEFcvp+QcPklBJit0xl1/J6TeqO1lll5QyybOfPjpiWMVJrWIOcaUyqi/G iXZDQBMTZz2iVCUQy/E68tn620lWu6b+p0E1w+CIYcmIx982ECKYWeqwSvtW FnNurE33IqFPrR16LUUn5TDBXvLaE8slQlGVRwOMbCHMdELtU/8zi48PVwEW L8+m7slwIhS9/b5sCwMwggOoMIICkKADAgECAghDZzmIviunRjANBgkqhkiG 9w0BAQUFADA/MQswCQYDVQQGEwJKUDETMBEGA1UEChMKRnVqaSBYZXJveDEb MBkGA1UEAxMSRnVqaSBYZXJveCBYbmV0IENBMB4XDTEyMDQwMjA4MjY1N1oX DTE0MDQwMTE0NTk1OVowSDELMAkGA1UEBhMCSlAxHTAbBgNVBAoTFEZ1amkg WGVyb3ggQ28uLCBMdGQuMRowGAYDVQQDExEyMjE0NiBTaGluIE9odGFrZTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoyYpIZWaOHMB3ikbUlamQSCT y1neW2nOWCamO5N96DwcKvnQ2EHZQfpDDmhZAjzQQ5IGpM/iuH4eQo2sZ+2E Q8gevzVDJW5nU2ypvT+yteWg/Qq6MzJjZLa4+Apt+rQVBrXBZeywXEI8vA/R 4HWIEVM/EqbxhIDssJNQYz2Foy8CAwEAAaOCASEwggEdMB8GA1UdIwQYMBaA FE2I1t2VWHXrrYgbTTIISciCBGCOMAkGA1UdEwQCMAAwPQYDVR0fBDYwNDAy oDCgLoYsaHR0cDovL2NhcHMuZnVqaXhlcm94LmNvLmpwL2NybC9meHhuZXRj YS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAsGA1UdDwQE AwIFoDBcBgNVHSAEVTBTMFEGCysGAQQBgikBBQEGMEIwQAYIKwYBBQUHAgEW NGh0dHA6Ly93d3cuZnVqaXhlcm94LmNvLmpwL3Byb2R1Y3QvY2FwL2Z4eG5l dGNhLmh0bWwwJgYDVR0RBB8wHYEbc2hpbi5vaHRha2VAZnVqaXhlcm94LmNv LmpwMA0GCSqGSIb3DQEBBQUAA4IBAQA9Uba8PJmVy+YCm0MRvfwSjE869c9o VrUj8KmXtOdkRp5A/wsVl1wJwSY95Zo97NzLgOynIp9k8ra4cKuqkirhJFOw lE6DUWpKi05fsZtHkgG/lhuv3b6haJMkjWlYikXWIRJ7TTK0cNIxsY8wobAG mMAwASc9bzKjs6GLkPFFuqOBUNL/k2NGbvNLlstrM6wN928GZWffgFm0aLM9 OOvdhQeZanEqoBWwhCI/2n3GmYA27W/V8Guf+a/E9nhcCKZIKR5+h8tXCaox D2tx3kV9xpO1NymsQsyLrHTpwwgvZNU0+TH1nUNFNlqLmxELy+X9ORzaMYqk PeGa9jQLvUWyMIIECzCCAvOgAwIBAgIJAUWZhr9bgFB4MA0GCSqGSIb3DQEB BQUAME8xCzAJBgNVBAYTAkpQMRMwEQYDVQQKEwpGdWppIFhlcm94MSswKQYD VQQDEyJGdWppIFhlcm94IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA4 MDQyOTE1MDAwMFoXDTE0MTIxNzAyMTMzMlowPzELMAkGA1UEBhMCSlAxEzAR BgNVBAoTCkZ1amkgWGVyb3gxGzAZBgNVBAMTEkZ1amkgWGVyb3ggWG5ldCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALV3iwzXlyB/xU98 aMEFsuTOg+ogQ903jg9N3md69FGcOgR4hN6f3n90z1d3yfy2CY/p11X2KIMm xth6CZYiporeXYwOGqgCie2cbZV09YISemQjKbavqk9wqsTR+IE/5+bdnY7s sbN0F06m+UmktqrcLl5AwTBb/fIA4NPy1gaFkFCub4zOnUHF9meIzkxq63LK Tmif48ZbI1frSF7HBGuJGaqTsHtBqvetbe+Nn15OcXrNwT7YdniukhqEWYSc qUnfNCjNWGp0viZB6a3wY7gOvsAT41OlWUrb5rCnDPbzCBojdWBBZB/QSNJq fgFgEhsLQh52/abm6f5d5UM9O10CAwEAAaOB+TCB9jALBgNVHQ8EBAMCAQYw HQYDVR0OBBYEFE2I1t2VWHXrrYgbTTIISciCBGCOMB8GA1UdIwQYMBaAFOrF p1bEKFI+gqXs9VAWY4/hiC15MFgGA1UdIARRME8wTQYLKwYBBAGCKQEFAQEw PjA8BggrBgEFBQcCARYwaHR0cDovL3d3dy5mdWppeGVyb3guY28uanAvcHJv ZHVjdC9jYXAvZnhjYS5odG1sMBIGA1UdEwEB/wQIMAYBAf8CAQAwOQYDVR0f BDIwMDAuoCygKoYoaHR0cDovL2NhcHMuZnVqaXhlcm94LmNvLmpwL2NybC9m eGNhLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAFfsmaMGjMqu0zTEvvAg/vkiP wzwCS3JwvTaH2R40sjZryCCN4e6yvm4aZHb86vzl/ngARXPh7lm3EMbMIMp9 M3EJhgvPgwxKH153+F31rKEPwaNWo3pQGxR7P8JxIOujZfSBoNL/bAqz+OZc I3B/LGhW6DTB4Qpatt4GZuf139CeMtW/qncnfY1snLHMlWsYzYn64+h69FwO B9ngfM6boxV3/sYAPGzjBH4IIlQ/1rpAWlIyEHoxQ15S/lVqclw7QC9D9giB Wv4/sy+80ZXsjVmhtTs42vJY3OWCy+3k0QDWNaDKlVzcmiAKWbd5jh2Ju8Im +PdmzsrEr4oEKHZyuTCCBCYwggMOoAMCAQICBBK5sKcwDQYJKoZIhvcNAQEF BQAwUDELMAkGA1UEBhMCSlAxGDAWBgNVBAoTD1NFQ09NIFRydXN0Lm5ldDEn MCUGA1UECxMeU2VjdXJpdHkgQ29tbXVuaWNhdGlvbiBSb290Q0ExMB4XDTA0 MTIxNzAyMTMzMloXDTE0MTIxNzAyMTMzMlowTzELMAkGA1UEBhMCSlAxEzAR BgNVBAoTCkZ1amkgWGVyb3gxKzApBgNVBAMTIkZ1amkgWGVyb3ggQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC3JDX7X4x3kY0YJbxMy2IbuJf7EshbOGJRnAQ3kT3GjMYdIHJM1+27 Mf+BO8XeSQx3FL0kExFylc1hkreCJ0CtZ3dpm/VGOxtIFgdySgi4XVp0qnnA QSjUk9amAXHUNs52UqkTPKPOq9UPkLhcw5XEOZptkHAsmNdla1aDB/iTr2m9 n/8IKAY+BLM3FhW4tBbbV5wPlDq71B7yTtnHdJqarPBp/lvngARpHWvbcQ4m fRRb1JaiiWKLHW+0V0ojwN754unS9fGY+WqM3l9gb26AYDI3JPzthJpxyhtu c5EmP3FjFmuRpK/Unqt8h8nBlqJ90GgY09qQvULrG36uiweZAgMBAAGjggEH MIIBAzAdBgNVHQ4EFgQU6sWnVsQoUj6Cpez1UBZjj+GILXkwHwYDVR0jBBgw FoAUoHNJmWjchVtl45soL1efvTO8B0gwEgYDVR0TAQH/BAgwBgEB/wIBATAO BgNVHQ8BAf8EBAMCAQYwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL3JlcG9z aXRvcnkuc2Vjb210cnVzdC5uZXQvU0MtUm9vdDEvU0NSb290MUNSTC5jcmww UgYDVR0gBEswSTBHBgoqgwiMmxtkhwUBMDkwNwYIKwYBBQUHAgEWK2h0dHBz Oi8vcmVwb3NpdG9yeS5zZWNvbXRydXN0Lm5ldC9TQy1Sb290MS8wDQYJKoZI hvcNAQEFBQADggEBAC3KeO2cIQO9t9UJXBPA4rbR4uxVxoqm8E4V34Em3CTB ZqZCJi1H9nkHBJ1dfRHctmb9vqG7LcPDMpSRHtKHYrOZAK/X4PTa7sK8ahVI 0+LaKmMnicff0xicQeVvPm6vbk7VKFRGqgaHm34AFy1Mb+Wp8W2XFZVwnBcZ RRgqfHsrYf4tkyGCMVh8H/f5QmExhyIGu9wS52rQPeLzA4BtIhC47a6aGgSx wfFK0ccMZlR974bDma+6Vb4hqzi1u9Aj5WtPiJ5x2+uRwWPlD0qjS0BMZ8x3 YvWfo5vB2pWz/jaT2fefw4WQiWFBKVPMXA2oE0v6T98qkSNEoGxMJ3eMS6Ax ggJ1MIICcQIBATBLMD8xCzAJBgNVBAYTAkpQMRMwEQYDVQQKEwpGdWppIFhl cm94MRswGQYDVQQDExJGdWppIFhlcm94IFhuZXQgQ0ECCENnOYi+K6dGMAkG BSsOAwIaBQCgggGAMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDcxMDA4NDI1MVowIwYJKoZIhvcNAQkEMRYEFBnxB0uJ YJtn7Qm+1pw0ojLl8rgpMFoGCSsGAQQBgjcQBDFNMEswPzELMAkGA1UEBhMC SlAxEzARBgNVBAoTCkZ1amkgWGVyb3gxGzAZBgNVBAMTEkZ1amkgWGVyb3gg WG5ldCBDQQIIQ2c5iL4rp0YwXAYLKoZIhvcNAQkQAgsxTaBLMD8xCzAJBgNV BAYTAkpQMRMwEQYDVQQKEwpGdWppIFhlcm94MRswGQYDVQQDExJGdWppIFhl cm94IFhuZXQgQ0ECCENnOYi+K6dGMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3 DQEBAQUABIGAWNz1rw2PKMojceZUyRSZPCL0cZbdpqEunfXA4D9u5i8isg77 U8Yz4NotEQrIgF2QQJFC5nc9gU1ip4FruPGqWuPZqRBCmVVp5kdVcUmqXrAZ rdRSqyJQ1D7+lWFcSnNR4tfKjaqDYArjNl/48qgclOruCKpJDWmWEJmSrp2A K14AAAAAAAA= ------=_NextPart_000_010A_01CE7D94.E674A900-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============1591068235== 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 --===============1591068235==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Wed Jul 17 10:31:54 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7E21F9371 for ; Wed, 17 Jul 2013 10:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=-2.514, 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 gy1COKb2hadf for ; Wed, 17 Jul 2013 10:31:48 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0221F9E33 for ; Wed, 17 Jul 2013 10:31:48 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 8C3AA791A1; Wed, 17 Jul 2013 13:31:11 -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 6965F7919C for ; Wed, 17 Jul 2013 13:30:46 -0400 (EDT) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ3007U8CM0V2N1@mail-out.apple.com> for ipp@pwg.org; Wed, 17 Jul 2013 10:30:41 -0700 (PDT) X-AuditID: 11807165-b7fac6d0000008c6-a5-51e6d4c0e810 Received: from [17.153.44.207] (Unknown_Domain [17.153.44.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 84.B3.02246.1C4D6E15; Wed, 17 Jul 2013 10:30:41 -0700 (PDT) From: Michael Sweet Date: Wed, 17 Jul 2013 13:30:45 -0400 To: "ipp@pwg.org" Message-id: <675A909C-C8FD-42DF-B413-5AD6B3D941F4@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUiOFPnvO7BK88CDebdULU4tu8li8WRb7EO TB5bT/5g85i3eDpTAFMUl01Kak5mWWqRvl0CV8b1KXuYCpaJVLxvncvawNgk1MXIwSEhYCJx c49EFyMnkCkmceHeerYuRi4OIYFeJonuEwsYQRJsAmoSvyf1sYLUMwskSCxo9QUJswioSvz/ 3MoMYgsL2Ej0Ny8Gs0UE5CXWtk1lArF5geIfnyxhh7D1JJb+m8MIsVZWYufvpAmM3LMQhs5C UgRiMwtoSyxb+JoZokRHYvJCqLC8xPa3c5hhSj6eP8K0gJFtFaNAUWpOYqW5XmJBQU6qXnJ+ 7iZGUEA1FKbuYGxcbnWIUYCDUYmH90XE00Ah1sSy4srcQ4wSHMxKIrwHLj8LFOJNSaysSi3K jy8qzUktPsQozcGiJM4bVf4gUEggPbEkNTs1tSC1CCbLxMEp1cC4J+H1yZvxJ/fxv5+wQSQ9 n6e//BbHimyJJdPkcu3yFHpYJOf+vXT+srOl8CKpOWf2O9xck8tyMkR6iUer8JWe8yzcfzZb fZynxNURu93E1/V+7d5zzJ+aYwq3/22W/afdlXGl5sLThpPLJSfNWiH8N6Qi5qbV2WxuyYxN /R+W5zncsZgjyjhZiaU4I9FQi7moOBEAOFLBvyQCAAA= X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] New Bonjour Printing specification now available... 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="===============0745280895==" 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: 8C3AA791A1.A8456 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============0745280895== Content-type: multipart/alternative; boundary="Boundary_(ID_9hsMt49pQ+y+jdPRi0fVTw)" --Boundary_(ID_9hsMt49pQ+y+jdPRi0fVTw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, We finally managed to get a new version of the Bonjour Printing specification published at: https://developer.apple.com/bonjour/printing-specification/ The current version is 1.2 and includes a couple additions from what is documented in the IPP Everywhere specification, namely a new PaperMax value and the new "kind" key that corresponds to the "printer-kind" attribute that is defined in the IPP Transaction-Based Printing Extensions specification. It also formally deprecates the keys used for driver selection (product, ty, usb_CMD, usb_MFG, usb_MDL) when printing using IPP/IPPS. Enjoy! _________________________________________________________ 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_9hsMt49pQ+y+jdPRi0fVTw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

We finally managed to get a new version of the Bonjour Printing specification published at:

    https://developer.apple.com/bonjour/printing-specification/

The current version is 1.2 and includes a couple additions from what is documented in the IPP Everywhere specification, namely a new PaperMax value and the new "kind" key that corresponds to the "printer-kind" attribute that is defined in the IPP Transaction-Based Printing Extensions specification.  It also formally deprecates the keys used for driver selection (product, ty, usb_CMD, usb_MFG, usb_MDL) when printing using IPP/IPPS.

Enjoy!

_________________________________________________________
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_9hsMt49pQ+y+jdPRi0fVTw)-- --===============0745280895== 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 --===============0745280895==-- From ipp-bounces@pwg.org Fri Jul 19 14:31:26 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964C511E817C for ; Fri, 19 Jul 2013 14:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 8lejzZzot7by for ; Fri, 19 Jul 2013 14:31:20 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB811E8138 for ; Fri, 19 Jul 2013 14:31:20 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 42DA8791D3; Fri, 19 Jul 2013 17:30:36 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by pwg.org (Postfix) with ESMTP id 25488791D2 for ; Fri, 19 Jul 2013 17:30:10 -0400 (EDT) Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 844141432F for ; Fri, 19 Jul 2013 21:30:10 +0000 (UTC) Received: from G4W6302.americas.hpqcorp.net (16.210.26.227) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Jul 2013 21:28:25 +0000 Received: from G4W3295.americas.hpqcorp.net ([169.254.3.144]) by G4W6302.americas.hpqcorp.net ([16.210.26.227]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 21:28:25 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "" Thread-Topic: Question concerning what the "IPP/2.0 Implementer's Guide" should recommend for multiple-document-handling vs. job-collate Thread-Index: AQHOhMbmgYfhU918HUSbYkphcwG0XQ== Date: Fri, 19 Jul 2013 21:28:24 +0000 Message-ID: <324FEB75-3DE6-4C8B-8846-49C58A991677@hp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [15.201.58.30] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Question concerning what the "IPP/2.0 Implementer's Guide" should recommend for multiple-document-handling vs. job-collate 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="===============2101196859==" 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: 42DA8791D3.A9262 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============2101196859== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_E3D5CAFF-350A-444F-8D59-D5C9402A485E"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_E3D5CAFF-350A-444F-8D59-D5C9402A485E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, I'm having trouble productively acting on the minutes from the May 2013 Fac= e-to-Face that recommend adding a section discussing multiple-document-hand= ling and job-collate to section 5: > =E2=80=A2 Section 5.x: Add multiple-document-handling and job-collate > =E2=81=83 Discuss use of multiple-document-handling for collation inste= ad > of job-collate because job-collate does not address number-up, > finishings, sides, etc. I spent a few minutes reading about multiple-document-handling and job-coll= ate and was confused: - I could not find a "job-collate" attribute, but I did find sheet-collate = (RFC 3381) - The "multiple-document-handling" attribute doesn't seem to have any metho= d of requesting number-up, finishings, sides. The set of keywords defined = for that in the IANA registry are all from RFC 2911: http://pwg.org/ipp/ipp-registrations.xml Here are the current keywords: separate-documents-collated-copies separate-documents-uncollated-copies single-document single-document-new-sheet The only thing that I could come up with connecting multiple-document-handl= ing to something like N-UP is that multiple-document-handling influences ho= w the documents are handled within a potentially multiple document job, whe= reas job-collate seems to influence how the entire job is rendered, and so = is somehow disconnected from finishings / finishings-col. I'm obviously missing something so if someone could point me in the right d= irection on this one that would be helpful. Thanks in advance, Smith /** Smith Kennedy Hewlett-Packard Co. smith.kennedy@hp.com */ --Apple-Mail=_E3D5CAFF-350A-444F-8D59-D5C9402A485E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIH2zCCB9cwgga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZI hvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMB4XDTEyMTEyNjAw MDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xldHQtUGFj a2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVt cGxveWVlczEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5u ZWR5MSMwIQYJKoZIhvcNAQkBFhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmoHmmwCMk0tCSI1w6tYppe JX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNNlmHy sW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTT tqMFk7JkrL1QH8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzm clRKpoDRKFT35bHptUCD0VR7IY749Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzO sQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU8Al3e/iq362nUqJm rFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWg MFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24u Y29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0Q1JMLmNy bDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQU 2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcG CCsGAQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsG AQUFBzACpIHnMIHkMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQt UGFja2FyZCBDb21wYW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhF AQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21w YW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3Jy ZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZp Y2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRo IEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFi LiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMC AgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEF BQADggEBAImyDkwpuUnbTsboOwpQAPQ4M1jbZkfWS/mLo6oj6XOWApq9IQ1j kwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnITaq9lFeagCZiq tFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVS kJN11A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+4 6gy6oM9LHtINt8Fclro/45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0W rlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xufBjNLp57JgbuFIg4xggTeMIIE 2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI /6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcxOTIxMjgyNFowIwYJKoZIhvcNAQkE MRYEFI4SqXNV5dSYRUZcDtr/KOpyNIt5MIIBHwYJKwYBBAGCNxAEMYIBEDCC AQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQg Q29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9u IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI/6Xyi7Fl MIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAe BgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMs Q2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex MTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgRzICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAaoh2 8GgBczsmNsl3D8By3y9gMTwio7dDTqI3edrjHToBoHYeQH4nqbTtuv3nzylE jQrV8w2QTP86fFFs7fa7aFIXUSC/JL+g05lH5XLichQl0x5wrQIM6Cs8HUWL vSdjQjRbtno/jYllJI2Q17rQKIXi8/qUEWSH0FJ+vOlCwNR1SLSSsGEb2pc0 9qluTjmcwvWXRl3FER1jRx7IY5KIeYG4PTGU+6+fqCMIqG+IQ2QKDq6YVxYA +46++wyeSp3G4YaxzwoZPL+mUjLsO2R9ht755KHlkmJv5kTmCcIfoDiwJKUN a1dnf/atftu+ZZEhp6Bjdn8PT1Rc9XhXNZNP6wAAAAAAAA== --Apple-Mail=_E3D5CAFF-350A-444F-8D59-D5C9402A485E-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============2101196859== 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 --===============2101196859==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Mon Jul 22 05:01:00 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8921E8056 for ; Mon, 22 Jul 2013 05:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185, 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 z-iJUSUXgjn9 for ; Mon, 22 Jul 2013 05:00:56 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id AA35821E8051 for ; Mon, 22 Jul 2013 05:00:55 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id B45BE791DB; Mon, 22 Jul 2013 08:00:19 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by pwg.org (Postfix) with ESMTP id B9A4C791AB for ; Mon, 22 Jul 2013 07:59:56 -0400 (EDT) Received: by mail-ie0-f170.google.com with SMTP id e11so15317668iej.29 for ; Mon, 22 Jul 2013 04:59:56 -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=cww87p7kqHSc+FJn4ZGWNDFqJvGRxEsOOFz/9n53KyE=; b=UOyuBspQI5fMsJ/PfeCcOy/xCAv+xOzda6g/1AB5yUDW2FvzO9vpVIA91Wrpdjlbgg iZwNiHciM8MkQkFq95PvIONAjkAeRfKVZBDNmXNSDUl8fF66mTJf9G1w4rqtarEX0kwb +lGrmQU0HKB2fIjd/JVLCOWKiRYyEPGf+4C/uCuyCC610zqjVIgJnqvr5O4RUSfL/V9i q19/6EqK8fN4a+CCN46EZUx2lRZ0gGyxWs1yoJa/ThD6vsdHIzOusG1FcHolyG9um9b6 kADyGzs+k5khKasQ8bb/e18TsQcJbfh+SKL/XARrta+j5uP053tG82pzC8y9Ck1K08ID JsUA== MIME-Version: 1.0 X-Received: by 10.50.79.167 with SMTP id k7mr9508665igx.56.1374494396246; Mon, 22 Jul 2013 04:59:56 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Mon, 22 Jul 2013 04:59:56 -0700 (PDT) Date: Mon, 22 Jul 2013 07:59:56 -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 22 July 2013 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="===============1520508331==" 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: B45BE791DB.A9504 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1520508331== Content-Type: multipart/alternative; boundary=089e013a1a383bf71204e2186a01 --089e013a1a383bf71204e2186a01 Content-Type: text/plain; charset=ISO-8859-1 Hi, Our next IPP WG call is this week Monday 22 July 12-2pm US Pacific / 3-5pm US Eastern Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll number (US/Canada): 1-650-429-3300 (Primary) Call-in toll number (US/Canada): 1-408-856-9570 (Backup) Attendee Access Code: *******# Attendee ID Code: # (empty) ------------------------------------------------------- Meeting information ------------------------------------------------------- Date: Every Monday, from Monday, July 9, 2012 to no end date Time: 12:00 pm, Pacific Daylight Time (San Francisco) Meeting Number: 624 587 312 Meeting Password: pwg123 ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://appleinc.webex.com/appleinc/j.php?ED=204995427&UID=504472682&PW=NNzM5MmRlMzBl&RT=MiM0 ------------------------------------------------------- Agenda: (1) PWG IP Policy and Minute Taker - Mike (2) Approve IPP minutes from previous meeting - ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130708.pdf (3) Status of IPP Transaction-based Printing Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708-rev.pdf - Mike to post PWG Last Call ending on 12 August 2013 (4) Status of IPP Fax Out (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130501.pdf - PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments (5) Status of IPP Self-Certification (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippselfcert10-20130501-rev.pdf - Updated ipptool and new ippfind (6) Status of IPP Implementor's Guide v2.0 (Smith) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipp-bestp10-20130513-rev.pdf - see Smith's email note on 19 July (7) Review of IPP Shared Infrastructure Extensions (Mike) - ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130705-rev.pdf - continue review at section 4.2.4 (8) Next steps - Cloud WG telecon on Monday 29 July - review Cloud & IPP F2F slides - IPP WG at PWG F2F on Tuesday 6 August - IPP WG at PWG F2F on Thursday 8 August 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --089e013a1a383bf71204e2186a01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Our next IPP= WG call is this week Monday 22 July 12-2pm US Pacific / 3-5pm US Ea= stern

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

Attendee A= ccess Code: *******#
Attendee ID Code: # (empty)

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

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

(2) Approve IPP minutes f= rom previous meeting
- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-c= oncall-minutes-20130708.pdf

(3) Status of IPP Transaction-base= d Printing Extensions (Mike)
- ftp://ftp.pwg.org/pub/= pwg/ipp/wd/wd-ipptrans10-20130708-rev.pdf
- Mike to post PWG Last Call ending on 12 August 2013

(4) Status of IPP Fax O= ut (Mike)
- PWG Last Call - ended 28 June - quorum achieved - 7 sets of comments=

(5) Status of IPP Self-Certification (Mike)
- ftp= ://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippselfcert10-20130501-rev.pdf
- Updated ipptool and new ippfind

(= 6) Status of IPP Implementor's Guide v2.0 (Smit= h)
- see Smith's email note on 19 July

(7) Review of IPP Share= d Infrastructure Extensions (Mike)
- continue review at section 4.2.4

(8) Next st= eps
- Cloud WG telecon on Monday 29= July - review Cloud & IPP F2F slides
- IPP WG at PWG F2F on Tuesday 6 August
- IPP WG at PWG F2F on Thursday 8 Augu= st

Cheers,
- Ira


Ira McDonald (Musician / Softwar= e Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IE= EE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chai= r - 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


--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. --089e013a1a383bf71204e2186a01-- --===============1520508331== 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 --===============1520508331==-- From ipp-bounces@pwg.org Mon Jul 22 05:20:43 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0B21E8087 for ; Mon, 22 Jul 2013 05:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=-2.487, BAYES_00=-2.599] 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 QjIFw0usodLu for ; Mon, 22 Jul 2013 05:20:31 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id B1D5B11E80ED for ; Mon, 22 Jul 2013 05:20:30 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 004AB791DF; Mon, 22 Jul 2013 08:20:01 -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 50C65791DC for ; Mon, 22 Jul 2013 08:19:33 -0400 (EDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQC004587KE3RZ0@mail-out.apple.com> for ipp@pwg.org; Mon, 22 Jul 2013 05:19:32 -0700 (PDT) X-AuditID: 11807153-b7fed6d0000060fa-73-51ed235215e5 Received: from [17.153.27.114] (Unknown_Domain [17.153.27.114]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 0E.34.24826.3532DE15; Mon, 22 Jul 2013 05:19:32 -0700 (PDT) Subject: Re: [IPP] Question concerning what the "IPP/2.0 Implementer's Guide" should recommend for multiple-document-handling vs. job-collate From: Michael Sweet In-reply-to: <324FEB75-3DE6-4C8B-8846-49C58A991677@hp.com> Date: Mon, 22 Jul 2013 08:19:31 -0400 Content-transfer-encoding: quoted-printable Message-id: <0E877BF2-2E2B-4898-AF3D-A6D32BDEC8D4@apple.com> References: <324FEB75-3DE6-4C8B-8846-49C58A991677@hp.com> To: "Kennedy, Smith (Wireless Architect)" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiOFO6SDdE+W2gQcNyFotj+16yWBz5Fmvx qmsXswOzx9aTP9g8dm3byeQxb/F0pgDmKC6blNSczLLUIn27BK6Ms6evMRUcEqtoeH6IuYHx klAXIweHhICJxI2Vxl2MnECmmMSFe+vZuhi5OIQEepkkFix6xgTiCAv0MkocvtzKBFLFK6An sfTfHEYQm1lAXeLPvEvMIDabgJrE70l9rCBDOQWsJBr7IkHCLAKqEsv/v2ODKFeUWDb9DyuE rS2xbOFrZoiRNhIbV19jAbGFBCwl9s2Zyw5iiwg4SDxf8okF4k5ZiZ2/kyYw8s9CcsQsJEfM QjJ1ASPzKkaBotScxEpjvcSCgpxUveT83E2MoBBsKAzewfhnmdUhRgEORiUe3oaAN4FCrIll xZW5hxglOJiVRHg9VwGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+75AZQSSE8sSc1OTS1ILYLJ MnFwSjUwJs6872I1Y85s9z/fJf/ekPdJeJIqbfbowaKnSpVGO+2Z/02882nH6xSOV331rAqd S9IzjbWs2Uw+GLScklh0fVfgCv1J5YfuLtTfd9/857SL/8WyDXwip89KFpda6nrUavb1mWHz /P53NvttK88y+fTVnOHMRPMrW2Z4Ol/Vn315eXLXpLlayUosxRmJhlrMRcWJAEYYn2k9AgAA X-pwg-MailScanner: Found to be clean, Found to be clean Cc: "" X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org X-pwg-MailScanner-Information: Please contact the ISP for more information X-pwg-MailScanner-ID: 004AB791DF.A9181 X-pwg-MailScanner-From: ipp-bounces@pwg.org Smith, On 2013-07-19, at 5:28 PM, "Kennedy, Smith (Wireless Architect)" wrote: > Greetings, >=20 > I'm having trouble productively acting on the minutes from the May 2013 F= ace-to-Face that recommend adding a section discussing multiple-document-ha= ndling and job-collate to section 5: >=20 >> =E2=80=A2 Section 5.x: Add multiple-document-handling and job-collate >> =E2=81=83 Discuss use of multiple-document-handling for collation inste= ad >> of job-collate because job-collate does not address number-up, >> finishings, sides, etc. >=20 > I spent a few minutes reading about multiple-document-handling and job-co= llate and was confused: >=20 > - I could not find a "job-collate" attribute, but I did find sheet-collat= e (RFC 3381) "sheet-collate" is the Job Template attribute and "job-collation-type" is t= he Job Description attribute. "sheet-collate" interacts with "multiple-doc= ument-handling" - see the unnumbered table on Page 5 of RFC 3381. > - The "multiple-document-handling" attribute doesn't seem to have any met= hod of requesting number-up, finishings, sides. The set of keywords define= d for that in the IANA registry are all from RFC 2911: "multiple-document-handling" defines how multiple documents/copies interact= with the other attributes, including sheet-collate. It is also the only a= ttribute that can be safely used to specified collated/uncollated copies fo= r single and multiple document jobs. > ... > The only thing that I could come up with connecting multiple-document-han= dling to something like N-UP is that multiple-document-handling influences = how the documents are handled within a potentially multiple document job, w= hereas job-collate seems to influence how the entire job is rendered, and s= o is somehow disconnected from finishings / finishings-col. Finishings operate on sets. So if you specify multiple-document-handling a= nd/or sheet-collate values that treat the copies as a single set ('single-d= ocument' + 'uncollated', for example) and request stapling, then all of the= copies get stapled together (probably not what you want...) There is some discussion of this for progress reporting in JPS3 (5100.13) t= hat might help to highlight some of the edge cases for things like number-u= p. .... One of the reasons we opted to use multiple-document-handling as the collat= e/uncollated copies knob in IPP Everywhere is that sheet-collate has some, = um, interesting interactions with multiple-document-handling that are not w= ell defined, whereas using multiple-document-handling for single-document j= obs avoids that complexity and provides a single knob for all kinds of jobs. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From ipp-bounces@pwg.org Mon Jul 22 11:01:54 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EDA11E80E7 for ; Mon, 22 Jul 2013 11:01:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY1ACWLUT5YG for ; Mon, 22 Jul 2013 11:01:45 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 883CE11E80D2 for ; Mon, 22 Jul 2013 11:01:42 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3E6D6791FA; Mon, 22 Jul 2013 14:00:55 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by pwg.org (Postfix) with ESMTP id 0BE59791FA for ; Mon, 22 Jul 2013 14:00:24 -0400 (EDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 406D32411B for ; Mon, 22 Jul 2013 18:00:24 +0000 (UTC) Received: from G4W6306.americas.hpqcorp.net (16.210.26.231) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 22 Jul 2013 18:00:05 +0000 Received: from G4W3295.americas.hpqcorp.net ([169.254.3.144]) by G4W6306.americas.hpqcorp.net ([16.210.26.231]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 18:00:05 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "" Thread-Topic: Discuss relationship between "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported" for IPP/2.0 Implementer's Guide Thread-Index: AQHOhwVLueh7xKCMdUCziYbBH9Df4g== Date: Mon, 22 Jul 2013 18:00:04 +0000 Message-ID: <84D7555A-60BB-45B2-87BC-63AB428E2163@hp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.28] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Discuss relationship between "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported" for IPP/2.0 Implementer's Guide 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="===============2112731285==" 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: 3E6D6791FA.A9AC2 X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============2112731285== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_90F94B02-AA2A-4938-81F9-D3CD64109129"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_90F94B02-AA2A-4938-81F9-D3CD64109129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, I should have posted this to the reflector following the May 2013 Face-to-F= ace. From that meeting, there was an action item to discuss the relationsh= ip between "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-o= verride". Here is my understanding of the these attributes and the roles they play: ipp-attribute-fidelity: if "true" then the attributes and attribute values = in the operation MUST be supported by the Printer. If not the Printer MUST= reject the operation. job-mandatory-attributes: lists the job attribute values the printer MUST s= upport. This allows the client to identify which ones are mandatory and wh= ich ones are optional. This seems to mean that sending job-mandatory-attri= butes listing all the job attributes the client intends to provide is equiv= alent to sending ipp-attribute-fideiity set to "true". pdl-override-supported: specifies whether the printer is capable of overrid= ing job attributes embedded in the job document(s) with IPP job attributes,= and with what level of reliability: "attempted" (RFC 2911), "not-attempted= " (RFC 2911), "guaranteed" (PWG 5100.11). Discussion of this in Section 15 (Appendix D) of RFC 2911 but recommendatio= ns for IPP Client and IPP Printer is still needed, hence the need for a sec= tion in the IPP/2.0 Implementer's Guide. Thoughts / questions to answer (incomplete list): 1. Is there a series of operations including particular attributes that a c= lient can use to reliably assess how to proceed with an IPP Printer that su= pports various pdl-override-supported values? 2. ipp-attribute-fidelity ONLY guarantees that the IPP attributes and attri= bute values are supported by the Printer. It does NOT guarantee that the a= ttributes and attribute values will affect the rendering of the job. So fo= r "modern" IPP clients and printers, should ipp-attribute-fidelity always b= e "true" if the Client is always able to acquire the attributes and attribu= te supported values? 3. ??? (I'm assuming that either this will trigger additional questions or will tr= igger an auto-immune response in someone who will put this discussion on th= e "right track".) Since this is posted so close to the meeting, perhaps we will discuss this = in person there. But I wanted to get this posted in case that doesn't occu= r. Smith /** Smith Kennedy Hewlett-Packard Co. smith.kennedy@hp.com */ --Apple-Mail=_90F94B02-AA2A-4938-81F9-D3CD64109129 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIH2zCCB9cwgga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZI hvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMB4XDTEyMTEyNjAw MDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xldHQtUGFj a2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVt cGxveWVlczEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5u ZWR5MSMwIQYJKoZIhvcNAQkBFhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmoHmmwCMk0tCSI1w6tYppe JX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNNlmHy sW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTT tqMFk7JkrL1QH8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzm clRKpoDRKFT35bHptUCD0VR7IY749Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzO sQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU8Al3e/iq362nUqJm rFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWg MFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24u Y29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0Q1JMLmNy bDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQU 2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcG CCsGAQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsG AQUFBzACpIHnMIHkMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQt UGFja2FyZCBDb21wYW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhF AQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21w YW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3Jy ZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZp Y2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRo IEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFi LiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMC AgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEF BQADggEBAImyDkwpuUnbTsboOwpQAPQ4M1jbZkfWS/mLo6oj6XOWApq9IQ1j kwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnITaq9lFeagCZiq tFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVS kJN11A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+4 6gy6oM9LHtINt8Fclro/45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0W rlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xufBjNLp57JgbuFIg4xggTeMIIE 2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI /6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcyMjE4MDAwNVowIwYJKoZIhvcNAQkE MRYEFMvCN3Df9NvhImEogOMtWitsWJAGMIIBHwYJKwYBBAGCNxAEMYIBEDCC AQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQg Q29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9u IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI/6Xyi7Fl MIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAe BgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMs Q2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex MTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgRzICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAEwt4 YGtZJz47c/fPO+NIqqbYCCENeDRh9sqafEiYcqaNLNNedj7Mf6QGLKbXh9Vb zlb/DksI4N5j4SRX9YU6abH+QX0eH9Ou8RcGnh61fFe7Nv/bBJKGBqdvOrKW 2aqhhnVD43PuyLYLPHwjUWBdhGxfgG2ntbCf3ydfObou1rHpYXUq70rUrhXD 8DIcwUgL1Tek75Np0Oqj3MCV0KBi/RqjBXQJpXT0Yw3sEGq7V2wn7P4I/Srj TMEbL6cM3cdnJB2b0w/ajSwnZrfR6RBgW9m8OCSaFwytJSe22u7BVGjUPArv XL/tIV6Kx6ma5OBw73lu+gl6l6nx3nKxT49O+gAAAAAAAA== --Apple-Mail=_90F94B02-AA2A-4938-81F9-D3CD64109129-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============2112731285== 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 --===============2112731285==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Mon Jul 22 11:24:44 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957AE11E812F for ; Mon, 22 Jul 2013 11:24:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOjH+VOmppW1 for ; Mon, 22 Jul 2013 11:24:38 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6387F11E811D for ; Mon, 22 Jul 2013 11:24:38 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 3054A7921A; Mon, 22 Jul 2013 14:23:57 -0400 (EDT) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by pwg.org (Postfix) with ESMTP id 0FFA779219 for ; Mon, 22 Jul 2013 14:23:32 -0400 (EDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 3F8158611 for ; Mon, 22 Jul 2013 18:23:32 +0000 (UTC) Received: from G4W6304.americas.hpqcorp.net (16.210.26.229) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 22 Jul 2013 18:23:15 +0000 Received: from G4W3295.americas.hpqcorp.net ([169.254.3.144]) by G4W6304.americas.hpqcorp.net ([16.210.26.229]) with mapi id 14.03.0123.003; Mon, 22 Jul 2013 18:23:16 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "" Thread-Topic: Updated draft of "IPP/2.0 Implementer's Guide" posted to PWG FTP site Thread-Index: AQHOhwiHHC/BbYqHg0GdoRuCZAti2g== Date: Mon, 22 Jul 2013 18:23:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.28] MIME-Version: 1.0 X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Updated draft of "IPP/2.0 Implementer's Guide" posted to PWG FTP site 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="===============1683777133==" 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: 3054A7921A.A900D X-pwg-MailScanner-From: ipp-bounces@pwg.org --===============1683777133== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_CD0AA44F-2626-48F6-BADA-9E3D9EEC22DA"; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail=_CD0AA44F-2626-48F6-BADA-9E3D9EEC22DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, I just posted an updated draft of the "IPP/2.0 Implementer's Guide" to the = PWG FTP site: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippig20-20130722-rev.pdf It is likely posted too late for discussion today, but I still wanted to ma= ke it available. Cheers, Smith /** Smith Kennedy Hewlett-Packard Co. smith.kennedy@hp.com */ --Apple-Mail=_CD0AA44F-2626-48F6-BADA-9E3D9EEC22DA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIH2zCCB9cwgga/oAMCAQICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZI hvcNAQEFBQAwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMB4XDTEyMTEyNjAw MDAwMFoXDTE0MTEyNjIzNTk1OVowgZgxIDAeBgNVBAoUF0hld2xldHQtUGFj a2FyZCBDb21wYW55MSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVt cGxveWVlczEPMA0GA1UECxMGUy9NSU1FMRYwFAYDVQQDEw1TbWl0aCBLZW5u ZWR5MSMwIQYJKoZIhvcNAQkBFhRzbWl0aC5rZW5uZWR5QGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmoHmmwCMk0tCSI1w6tYppe JX3YINwFC5wUIhCt8HcRW/Ass9n7BxP1MpBUScmYpaQOjFI+n6JueqNNlmHy sW9wFG8FiSxowAf2C6cN+kmrV1MOzprrpjZZTB979lqRD/UG5RCo4BNy3aTT tqMFk7JkrL1QH8yLa5IOgUd36N7bK3+nSz6W3X3jo5G8Eax5xJvwCioOQzzm clRKpoDRKFT35bHptUCD0VR7IY749Ik7+A4RBp52w7zKYrs6N59Hy0PxxEzO sQImUC7++mhRJtg5AdX75wAKb665v3b4RZjJBMQhjYdU8Al3e/iq362nUqJm rFbNhpM9LSapjpbCm7ECAwEAAaOCA7owggO2MB8GA1UdEQQYMBaBFHNtaXRo Lmtlbm5lZHlAaHAuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWg MFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24u Y29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0Q1JMLmNy bDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQU 2ugcyk1Ph3Uvd67i/95+2TE174IwggEyBggrBgEFBQcBAQSCASQwggEgMCcG CCsGAQUFBzABhhtodHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsG AQUFBzACpIHnMIHkMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQt UGFja2FyZCBDb21wYW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhF AQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21w YW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3Jy ZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZp Y2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRo IEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFi LiBsdGQuIChjKTk3IFZlcmlTaWduMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwME MEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMC AgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZIhvcNAQEF BQADggEBAImyDkwpuUnbTsboOwpQAPQ4M1jbZkfWS/mLo6oj6XOWApq9IQ1j kwowCWwwCA3F3wCbKQGphJ8HdLaVGY9AznOEQoixLHx9rnITaq9lFeagCZiq tFq6/i33etWRb6dXp3FZYn9ikhYv74Ewil/ue61VqW9vOAZq51Wt9JznLmVS kJN11A4oJxNL8/jiK82tSXMkUHe07VbZUUF+t609D979rvVK68sw6P+cDe+4 6gy6oM9LHtINt8Fclro/45hQe0FdW1A1dmyx4dyKW/SbRK4uw5c0nXvaZn0W rlnq2Rxm/wCNKnGxAtp0ir7/7ubR6GjB3xufBjNLp57JgbuFIg4xggTeMIIE 2gIBATCCAQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJv cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI /6Xyi7FlMAkGBSsOAwIaBQCgggKlMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDcyMjE4MjMxNFowIwYJKoZIhvcNAQkE MRYEFGM5BDVBLU0nynKHMKsCxaNibBZrMIIBHwYJKwYBBAGCNxAEMYIBEDCC AQwwgfcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQg Q29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9u IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyAhA85d9RQjqi82zI/6Xyi7Fl MIIBIQYLKoZIhvcNAQkQAgsxggEQoIIBDDCB9zELMAkGA1UEBhMCVVMxIDAe BgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMs Q2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Ex MTAvBgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgRzICEDzl31FCOqLzbMj/pfKLsWUwDQYJKoZIhvcNAQEBBQAEggEAYVKU 0oYQGgrRMhHOOqk+LSVxZ0lU1sI5cPiB6xvB0+rEORV672QWyL9FrSQ+mtK9 2d5cB/7cnH4gqn5YWz2nYlhOeObi9D3+0ZexGL17Le9k/97VHrJzrejLS+Jc MSphYNvf1bvCEv2bWSqxQ1dDLk85dAlHDVn9NavbYrJLtp8QEQ1208UmVkn8 YP2S4Pv4+55lC90gr2sTd3DuI60OqxG1mPfdP9xH5JLPf5llHpDtpDkD5i2i EIRVsnaMPkfkVUCCsgxJK9RlaE8svaDDLUYofNk9G/5BC3j7u8DnNqRVjDoX GW6mGAedSrTcDc4LuF3575Wl1cM0nUJjiZUUXwAAAAAAAA== --Apple-Mail=_CD0AA44F-2626-48F6-BADA-9E3D9EEC22DA-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --===============1683777133== 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 --===============1683777133==-- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ipp-bounces@pwg.org Mon Jul 22 14:22:46 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181611E8164 for ; Mon, 22 Jul 2013 14:22: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFnvPWof4BfL for ; Mon, 22 Jul 2013 14:22:40 -0700 (PDT) Received: from pwg.org (pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id BF41311E8150 for ; Mon, 22 Jul 2013 14:22:40 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 2C77F7922A; Mon, 22 Jul 2013 17:21:55 -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 BFB8579229 for ; Mon, 22 Jul 2013 17:21:30 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQC008S0WNLVM11@mail-out.apple.com> for ipp@pwg.org; Mon, 22 Jul 2013 14:21:29 -0700 (PDT) X-AuditID: 11807157-b7fb46d000001149-1f-51eda2570fd3 Received: from [17.153.48.246] (Unknown_Domain [17.153.48.246]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 20.CF.04425.852ADE15; Mon, 22 Jul 2013 14:21:29 -0700 (PDT) From: Michael Sweet Date: Mon, 22 Jul 2013 17:21:25 -0400 To: ipp@pwg.org Message-id: <0079B7BE-0CC2-459C-B341-4BFA226F7F4B@apple.com> X-Mailer: Apple Mail (2.1786.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDJMWRmVeSWpSXmKPExsUiONPgm27koreBBgvnqFkc2/eSxeLIt1gH Jo+tJ3+wecxbPJ0pgCmKyyYlNSezLLVI3y6BK2PF7sWsBV+YKtbPfsnUwLiNqYuRk0NCwERi 0/YWFghbTOLCvfVsXYxcHEICvUwSLX2NbCAJNgE1id+T+lhBbGYBLYkb/14yQdjaEssWvmYG sVkEVCV+XXkDViMsYCDxtX0vWI2IAL/ExIsQvbwCNhJrGtYB2RxAtoHEjIMcEHvlJVY8usY2 gZFnFpINs5BsmIXQsYCReRWjQFFqTmKliV5iQUFOql5yfu4mRlCYNBSG72D8t8zqEKMAB6MS D+8C37eBQqyJZcWVuYcYJTiYlUR4N+oBhXhTEiurUovy44tKc1KLDzFKc7AoifPOcAFKCaQn lqRmp6YWpBbBZJk4OKUaGB2P7Tq4Lke761vc5VrHicaTmBgn9kWff3kjewWH1rr82exe/FEX JEXvmQb+PHr7XJWC+d5PbsUzDR+7bOD7z8MlY6TS98ju+0YxQWn1ahWPtG1nGvYeeRQS+qua U/7bU7mCaK2vjiuTtv/cucX0r8qUW59WNfgnnC15dqTkVnvzm9oFKT/nXlBiKc5INNRiLipO BABwieuNDwIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [IPP] Minutes posted from today's IPP concall 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: 2C77F7922A.A88A3 X-pwg-MailScanner-From: ipp-bounces@pwg.org 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-20130722.pdf Out next meeting is joint with Cloud on July 29, 2013 at 3pm to go through slide review. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp From pwg-announce-bounces@pwg.org Tue Jul 23 11:24:30 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AD811E8313 for ; Tue, 23 Jul 2013 11:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 JQ6xixigoPA6 for ; Tue, 23 Jul 2013 11:24:24 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60B11E8307 for ; Tue, 23 Jul 2013 11:24:16 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id 0487B79229; Tue, 23 Jul 2013 14:23:09 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by pwg.org (Postfix) with ESMTP id 46B9A79227 for ; Tue, 23 Jul 2013 14:22:43 -0400 (EDT) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQE00EI5J0SGGP0@mail-out.apple.com> for pwg-announce@pwg.org; Tue, 23 Jul 2013 11:22:26 -0700 (PDT) X-AuditID: 11807166-b7f4a6d000003873-4d-51eec9e14a95 Received: from [17.153.40.96] (Unknown_Domain [17.153.40.96]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 61.43.14451.2E9CEE15; Tue, 23 Jul 2013 11:22:26 -0700 (PDT) From: Michael Sweet Message-id: <5CF7D3D7-DEB3-44F8-9AED-2C6B29BEEE6D@apple.com> Date: Tue, 23 Jul 2013 14:22:30 -0400 To: "PWG Announcements Inc." X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42IRnKmRoPvo5LtAgye7TCzWta5mdmD0mLd4 OlMAYxSXTUpqTmZZapG+XQJXxqeJL9kKLslUTNrWydjA+Faii5GTQ0LAROLsqQ5mCFtM4sK9 9WwgtpBAN5PEvs2qIDabgJrE70l9rCA2s0CCxIMNf8HqhQVcJVp3dDKB2LwCNhJz320BinNw sAioSiy9zQUSFhEwltjRvpcNokRPYum/OYwgJRICshI7fydNYOSehWToLCRVEHFtiWULXwPF OYBsHYnJC9GEIeyP548wLWBkW8UoUJSak1hpoZdYUJCTqpecn7uJERRADYVpOxibllsdYhTg YFTi4S2Y9S5QiDWxrLgy9xCjBAezkgjvUimgEG9KYmVValF+fFFpTmrxIUZpDhYlcd5ZLm8D hQTSE0tSs1NTC1KLYLJMHJxSDYzG4bsbUxNuxubHnH3NO48pxO/7iuSe6hMTDmRYv93oYrZj +rxbi5zTVayck+uf9Vh2lXEfbjG7rG+z7fXx1rdMG0wc9fs1LH03/S3Zd+PSDMeQzwpfdKRO NEp89J4/oSyhf17dI4XJe39oGqdkl1XcXNBxdv+uLc3rJlqldr5zl7qb92Vn+w0lluKMREMt 5qLiRACK0EuQHAIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] [REMINDER] PWG August 2013 Face-to-Face Meeting in Camas, WA 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="===============0458850176==" 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: 0487B79229.AD3A7 X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============0458850176== Content-type: multipart/alternative; boundary="Boundary_(ID_/3Z9f5aB9eXBWBFfyDyMdQ)" --Boundary_(ID_/3Z9f5aB9eXBWBFfyDyMdQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT [This is a reminder to go to the survey page if you intend to go to the meeting and haven't already signed up...] All, The August 2013 PWG face-to-face meeting page is now available. The agenda and venue information can be found at: http://www.pwg.org/chair/meeting-info/august_2013_camas.html This page will be updated with document links as the material becomes available. Please visit the August 2013 survey page PRIOR TO August 2, 2013 and indicate whether you plan to participate in person or call in: http://www.surveymonkey.com/s/HD7Q5X8 For those not able to attend in person, the usual telephone bridge number will be provided. The details of the conference call are: Call-in toll-free number (US/Canada): +1 866 469-3239 Call-in toll number (US/Canada): +1 650 429-3300 Call-in toll number (US/Canada): +1 408 856-9570 Attendee access code: Please request from the PWG Chair (msweet@apple.com) if you need it. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --Boundary_(ID_/3Z9f5aB9eXBWBFfyDyMdQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
[This is a reminder = to go to the survey page if you intend to go to the meeting and haven't alr= eady signed up...]


All,

The Augus= t 2013 PWG face-to-face meeting page is now available. The agenda and venue=  information can be found at:

http://www.pwg.org/chair/meeting-info/august_= 2013_camas.html

This page will be updated with document links as= the material becomes available.

Please visit the August 2013 survey= page PRIOR TO August 2, 2013 and indicate whether you plan to partici= pate in person or call in:

h= ttp://www.surveymonkey.com/s/HD7Q5X8

For those not able to atten= d in person, the usual telephone bridge number will be provided. The d= etails of the conference call are:

Call-in toll-free number (US/Cana= da): +1 866 469-3239
Call-in toll number (US/Canada): +1 650 429-3300Call-in toll number (US/Canada): +1 408 856-9570

Attendee access co= de: Please request from the PWG Chair (msweet@apple.com) if you need i= t.

____________________= _____________________________________
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_/3Z9f5aB9eXBWBFfyDyMdQ)-- --===============0458850176== 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 --===============0458850176==-- From pwg-announce-bounces@pwg.org Thu Jul 25 04:35:30 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0921F99EE for ; Thu, 25 Jul 2013 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRCyJhhKA-nd for ; Thu, 25 Jul 2013 04:35:24 -0700 (PDT) Received: from pwg.org (www.pwg.org [192.146.101.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9229321F99CF for ; Thu, 25 Jul 2013 04:35:24 -0700 (PDT) Received: from pwg.org (localhost.localdomain [127.0.0.1]) by pwg.org (Postfix) with ESMTP id BD23F79216; Thu, 25 Jul 2013 07:34:35 -0400 (EDT) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by pwg.org (Postfix) with ESMTP id D7BEB79215 for ; Thu, 25 Jul 2013 07:34:10 -0400 (EDT) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQH00IF6PGX0J80@mail-out.apple.com> for pwg-announce@pwg.org; Thu, 25 Jul 2013 04:34:09 -0700 (PDT) X-AuditID: 11807143-b7fe56d000007efd-a6-51f10d30e652 Received: from [17.153.39.130] (Unknown_Domain [17.153.39.130]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id FE.9F.32509.13D01F15; Thu, 25 Jul 2013 04:34:09 -0700 (PDT) From: Michael Sweet Date: Thu, 25 Jul 2013 07:34:09 -0400 To: "PWG Announcements Inc." Message-id: <459C4A2B-09F1-42DC-8CA8-3B27B5117B06@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUiOFO9SdeQ92OgwawtxhZHvsVarGtdzezA 5LH15A82j3mLpzMFMEVx2aSk5mSWpRbp2yVwZTz/XFCwWrRizpSdzA2Mz4W6GDk5JARMJHa0 djFC2GISF+6tZ+ti5OIQEuhlkmj9eokNJMEmoCbxe1IfK4jNLJAg8an1IXMXIwcHi4CqxOJW cZCwsIClxPfV99hBbBEBY4kd7XvBWnkFbCS+bNvMCGHrSSz9N4cRpFVCQFZi5++kCYzcs5AM nYWkCiKuLbFs4WugOAeQrSMxeSGaMIT98fwRpgWMbKsYBYpScxIrjfQSCwpyUvWS83M3MYJC qqHQeQfjsWVWhxgFOBiVeHgDvr4PFGJNLCuuzD3EKMHBrCTCG1vxIVCINyWxsiq1KD++qDQn tfgQozQHi5I4r0cmUEogPbEkNTs1tSC1CCbLxMEp1cDYWfWN3av9l2vKnZ02KUyMNQaCQay/ hLwYDzU84Vepe1lXo2bJdqtkYYfQZMG7PyK2fi/nPPwifovwh7f/Jhl8Nu4/V2jzxjmXt8fK /KmSa++KkJh/XLfMH/z+sLPTXjphh09l+5lpe4qOWiU8mniF37Zx3ZnHgnoTXp2IdWmynS8h IM28/LsSS3FGoqEWc1FxIgCZBnBsJQIAAA== X-pwg-MailScanner: Found to be clean, Found to be clean Subject: [Pwg-Announce] Planned upgrade of pwg.org server happening soon 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="===============2045587145==" 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: BD23F79216.AC9EF X-pwg-MailScanner-From: pwg-announce-bounces@pwg.org --===============2045587145== Content-type: multipart/alternative; boundary="Boundary_(ID_uOaSSNz2YfUbsFEr0xFqIw)" --Boundary_(ID_uOaSSNz2YfUbsFEr0xFqIw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, The planned upgrade of pwg.org will be happening starting today, July 25, through tomorrow July 26. Please refrain from uploading any files to the FTP server or posting messages to the mailing lists until you see my follow-up "all clear" message. _________________________________________________________ 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_uOaSSNz2YfUbsFEr0xFqIw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable All,

T= he planned upgrade of pwg.org will be happen= ing starting today, July 25, through tomorrow July 26.  Please refrain= from uploading any files to the FTP server or posting messages to the mail= ing lists until you see my follow-up "all clear" message.

____________= _____________________________________________
Michael Sweet, Senior Prin= ting 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_uOaSSNz2YfUbsFEr0xFqIw)-- --===============2045587145== 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 --===============2045587145==-- From ipp-bounces@pwg.org Thu Jul 25 10:47:48 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D022C21F85EB for ; Thu, 25 Jul 2013 10:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrj90ZAlMUIl for ; Thu, 25 Jul 2013 10:47:43 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 43C4221F8445 for ; Thu, 25 Jul 2013 10:47:43 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 34A7E8A3C; Thu, 25 Jul 2013 17:51:17 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from www.msweet.org (li219-91.members.linode.com [173.255.209.91]) by www.pwg.org (Postfix) with ESMTP id 2C5C48A3B for ; Thu, 25 Jul 2013 17:51:16 +0000 (UTC) Received: from [10.0.1.32] (208-96-65-222.eastlink.ca [208.96.65.222]) by www.msweet.org (Postfix) with ESMTPSA id 2A82BC123; Thu, 25 Jul 2013 13:47:38 -0400 (EDT) From: Michael Sweet Date: Thu, 25 Jul 2013 13:47:43 -0400 To: "" Message-Id: <31AFBB4B-F432-41EF-812D-7C7110E11B27@msweet.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPP] Test message 2 X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0774767663==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0774767663== Content-Type: multipart/alternative; boundary="Apple-Mail=_EAEF9D08-007B-471D-90EA-BAF98A851D3F" --Apple-Mail=_EAEF9D08-007B-471D-90EA-BAF98A851D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a second test message from a new subscription (first might still = be waiting on DNS updates...) _____________ Michael Sweet --Apple-Mail=_EAEF9D08-007B-471D-90EA-BAF98A851D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = is a second test message from a new subscription (first might still be = waiting on DNS updates...)

_____________
Michael = Sweet

= --Apple-Mail=_EAEF9D08-007B-471D-90EA-BAF98A851D3F-- --===============0774767663== 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 --===============0774767663==-- From ipp-bounces@pwg.org Thu Jul 25 19:35:46 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAF421F888F for ; Thu, 25 Jul 2013 19:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgn4Rj8-1TW6 for ; Thu, 25 Jul 2013 19:35:40 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB3621F87B7 for ; Thu, 25 Jul 2013 19:35:40 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id B94558B37; Fri, 26 Jul 2013 02:39:16 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 2115F8B36 for ; Fri, 26 Jul 2013 02:39:15 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQI001SK6680EM1@mail-out.apple.com> for ipp@pwg.org; Thu, 25 Jul 2013 10:35:01 -0700 (PDT) X-AuditID: 11807158-b7f4d6d0000074f5-02-51f161c3d567 Received: from [17.153.39.130] (Unknown_Domain [17.153.39.130]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 31.E4.29941.4C161F15; Thu, 25 Jul 2013 10:35:01 -0700 (PDT) From: Michael Sweet Date: Thu, 25 Jul 2013 13:35:05 -0400 To: "" Message-id: X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUiOFO9Sfdo4sdAg43v+C2O7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlfFm5mGmgkcCFXtvuzUw/uPrYuTkkBAwkTi4 eysrhC0mceHeerYuRi4OIYFeJokrbROZQBJsAmoSvyf1gRUxCyRI9GzaCRTn4GARUJV4+JgL JCwsICrxas4UdhBbREBR4ue07YwgNq+AjcTcf7eYIWw9iaX/5jCCtEoIyErs/J00gZF7FpKh s5BUQcTlJba/ncM8C6iDWUBHYvJCqLC2xLKFr5lh7I/njzAtYGRbxShQlJqTWGmql1hQkJOq l5yfu4kRFFINhRE7GP8vszrEKMDBqMTDq+D0MVCINbGsuDL3EKMEB7OSCK+5JVCINyWxsiq1 KD++qDQntfgQozQHi5I4r1fmh0AhgfTEktTs1NSC1CKYLBMHp1QD45zjH9nWT5Pm8+69YBNY l/ov+uONs69l5bz3KH80eeXnNvkr0/lf5+tOTnPRXtx92FBxhl+TcJNRX3Vp0K3IpW2VgXXN pzdd3zZrkbysZNp8mZK5BQXX7u1J7F1k2SwpHsZjq6QWfSR3Ls8lbdc3BeL7sxVnt/4VWX/8 f/7+aVpp5115dDfOUmIpzkg01GIuKk4EAMRoj1slAgAA Subject: [IPP] Test message X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1430833452==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1430833452== Content-type: multipart/alternative; boundary="Boundary_(ID_sWF1G++UdjSGbcDv+qCMJg)" --Boundary_(ID_sWF1G++UdjSGbcDv+qCMJg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT This is a test. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_sWF1G++UdjSGbcDv+qCMJg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable This = is a test.

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

= --Boundary_(ID_sWF1G++UdjSGbcDv+qCMJg)-- --===============1430833452== 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 --===============1430833452==-- From pwg-announce-bounces@pwg.org Thu Jul 25 19:52:27 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C253F21F8EC3 for ; Thu, 25 Jul 2013 19:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78bPpPw7eFIH for ; Thu, 25 Jul 2013 19:52:22 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD721F8EB5 for ; Thu, 25 Jul 2013 19:52:22 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 89D188BBF; Fri, 26 Jul 2013 02:55:59 +0000 (UTC) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 898BD8BB9 for ; Fri, 26 Jul 2013 02:55:57 +0000 (UTC) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQI001L36XE0EN1@mail-out.apple.com> for pwg-announce@pwg.org; Thu, 25 Jul 2013 10:51:32 -0700 (PDT) X-AuditID: 11807165-b7fac6d0000008c6-a4-51f165a214be Received: from [17.153.39.130] (Unknown_Domain [17.153.39.130]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 2F.28.02246.3A561F15; Thu, 25 Jul 2013 10:51:31 -0700 (PDT) From: Michael Sweet In-reply-to: <459C4A2B-09F1-42DC-8CA8-3B27B5117B06@apple.com> Date: Thu, 25 Jul 2013 13:51:36 -0400 Message-id: References: <459C4A2B-09F1-42DC-8CA8-3B27B5117B06@apple.com> To: "PWG Announcements Inc." X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUiOFO9SXdx6sdAg4+TTSyOfIu1WNe6mtmB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgytj2/y9rQaNexbGPN5kbGPdpdDFyckgImEh8 mHedBcIWk7hwbz1bFyMXh5BAL5PEup6PbCAJZoEEiZdv9zCC2LwCehJL/80Bs4UFAiROtM5n BrHZBNQkfk/qYwWxOQVsJTq6FwL1cnCwCKhK7JjuD9FqI7H81xWwViEge8GpX+wgtoiAscSO 9r1g5RICshI7fydNYOSdhWTxLCSLIeLaEssWvmaeBdTBLKAjMXkhmjCE/fH8EaYFjGyrGAWK UnMSK831EgsKclL1kvNzNzGCgrChMHUHY+Nyq0OMAhyMSjy8Ck4fA4VYE8uKK3MPMUpwMCuJ 8JpbAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzemd+CBQSSE8sSc1OTS1ILYLJMnFwSjUwrjHI ft7Pa9FnpnZqtoFvyaxil2c6wgIzfhYv3nXvzGzGfNbWzK0Xpj/8uSh9vZmiIAObpvm99JX1 Kprhoqdu7jWe7aB4WmN2UbXFTpu9Htkd/VduJzNO8703O2365c1743ksaxlvb0g/dy0tl2H7 7dyMO5qZJq0MUwvKj+g0Xp6oNLPcvfquEktxRqKhFnNRcSIAvwPk9z4CAAA= Subject: [Pwg-Announce] COMPLETED - ALL CLEAR: Planned upgrade of pwg.org server happening soon X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121895691==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org --===============0121895691== Content-type: multipart/alternative; boundary="Boundary_(ID_3ZuNuiIk6RG0K+i9Y712wg)" --Boundary_(ID_3ZuNuiIk6RG0K+i9Y712wg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, The upgrade has been completed successfully and the new server is now online. It may still take up to a day for the DNS changes to propagate to everyone - please let me know if you experience any difficulties. Thank you! On 2013-07-25, at 7:34 AM, Michael Sweet wrote: > All, > > The planned upgrade of pwg.org will be happening starting today, July 25, through tomorrow July 26. Please refrain from uploading any files to the FTP server or posting messages to the mailing lists until you see my follow-up "all clear" message. > > _________________________________________________________ > 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 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_3ZuNuiIk6RG0K+i9Y712wg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable msweet@apple.com> = wrote:

pwg.org will be happening starting today, = July 25, through tomorrow July 26.  Please refrain from uploading = any files to the FTP server or posting messages to the mailing lists = until you see my follow-up "all clear" = message.

_________________________________________________________
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.
_______________________________________________
pwg-announce mailing = list
pwg-announce@pwg.org
https://w= ww.pwg.org/mailman/listinfo/pwg-announce

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

= --Boundary_(ID_3ZuNuiIk6RG0K+i9Y712wg)-- --===============0121895691== 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 --===============0121895691==-- From ipp-bounces@pwg.org Fri Jul 26 12:57:23 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4211E8127 for ; Fri, 26 Jul 2013 12:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.924 X-Spam-Level: X-Spam-Status: No, score=0.924 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lDLQltxrA-k for ; Fri, 26 Jul 2013 12:57:19 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 4036011E80FB for ; Fri, 26 Jul 2013 12:57:19 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id EA5EC8FC8; Fri, 26 Jul 2013 20:00:59 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from bware2.sdsamerica.net (bware2.sdsamerica.net [206.67.236.192]) by www.pwg.org (Postfix) with ESMTP id D22AF8FAA; Fri, 26 Jul 2013 20:00:56 +0000 (UTC) From: Ron Nevo To: "cloud@pwg.org" , "ipp@pwg.org" Thread-Topic: correction- Conference Call Monday 29 July at 3PM ET (IPP and Cloud) Thread-Index: Ac6KOlCZYVdI6FJqRKuHcz+XsOnJEg== Date: Fri, 26 Jul 2013 19:57:11 +0000 Message-ID: <1C6085AE4073A9448F7C718CC7EE1DEB10442C@SEAMBX2.sea.samsung.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: MIME-Version: 1.0 Received-SPF: none Subject: [IPP] correction- Conference Call Monday 29 July at 3PM ET (IPP and Cloud) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643236701==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0643236701== Content-Language: en-US Content-Type: multipart/related; boundary="_005_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_"; type="multipart/alternative" --_005_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_ Content-Type: multipart/alternative; boundary="_000_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_" --_000_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will be a Cloud/IPP conference call on Monday, 29 July at 3PM EDT (= Noon PDT). 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 Telecom Date: Every Monday, from Monday, OCT 29, 2012 to no end date Time: 12:00 pm, Pacific Daylight Time (San Francisco) Meeting Number: 624 587 312 Meeting Password: pwg123 ------------------------------------------------------- Go to https://appleinc.webex.com/appleinc/j.php?ED=3D204995427&UID=3D504472= 682&PW=3DNNzM5MmRlMzBl&RT=3DMiM0 Agenda: (1) PWG IP Policy and Minute Taker (2) IPP F2F slides (3) Cloud F2F slides Thank You, [Description: Description: samsung] Ron Nevo | Senior Manager | Product Marketing Strategic Alliances, Solutions, MPS, Standards and Certifications Chair IEEE/ISTO Printer Working Group-Cloud Imaging Samsung Electronics America, Inc. Enterprise Business Division 85 Challenger Road | Ridgefield Park, NJ 07660 P 201.329.6231 C 201.220.6348 rnevo@sea.samsung.com http://www.samsung.com/us/printersolutions/ [Print Plus Logo email version] --_000_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There will be a Cloud/IPP conference call on Monday,=  29 July  at 3PM EDT ( Noon PDT).

 

  Call-in toll-f= ree 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 Telecom 
Date: Every Monday, from Monday, OCT <= span style=3D"color:#1F497D"> 29, 2012 to no end date 
Time: 12:00 pm, Pacific Daylight Time (San Francisco) 
Meeting Number: 624 587 312 
Meeting Password: pwg123 

------------------------------------------------------- 
Go to https://apple= inc.webex.com/appleinc/j.php?ED=3D204995427&UID=3D504472682&PW=3DNN= zM5MmRlMzBl&RT=3DMiM0 



Agenda:

(1) PWG IP Policy and Minute Taker
(2) IPP F2F slides

(3) Cloud F2F slides

 

 

 

Thank You,<= /span>

 

3D"Description:

Ron Nevo | Senior Manager | Product Marketing

Strat= egic Alliances, Solutions, MPS, Standards and Certifications

Chair = IEEE/ISTO Printer Working Group-Cloud Imaging

Samsu= ng Electronics America, Inc.

Enter= prise Business Division

&nb= sp;

85 Chall= enger Road | Ridgefield Park, NJ 07660

P 201.329.6231  = ; C 201.220.6348

rnevo@sea.samsung.com
http://www.samsung.com/us/printersolu= tions/

3D"Print

--_000_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_-- --_005_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2235; creation-date="Fri, 26 Jul 2013 19:57:11 GMT"; modification-date="Fri, 26 Jul 2013 19:57:11 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAwAIADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAopKxNW8ZaDouVu9QjMo/5ZRfO/5Dp+NVGMpO0VcTkoq7ZuUV5hqfxeYkppWmgDtJct/wCyj/Gu V1Dxz4k1EkS6pJCh/ggxGP05/WuyGAqy30OWWLprbU9yub21s133VzDAvrI4X+dYd34/8MWeQ2qx ysP4YVL/AMhXhksjzPvmkaRj/E7Fj+tN7V1xy6C+KRhLGy6I9dufi1osfFvZ3k/uVVB+prMn+ML/ APLvooHvJP8A4CvNQQehBozW6wNBdDF4qq+p30nxd1c/6vTbJfqXP9RUB+LGvk8W1iP+AN/jXEZH rRketaLC0V9kn6xV7ndJ8WtdU/PZ2L/8BYf1q3B8YLoEfadHiYd/KmI/mK86oBB6EGk8JQf2QWIq rqexaf8AFXQbpgl2lxZMe7ruUfiv+FdfZ3trqFutxZ3Ec8LdHjYMK+bq3/BWs3mkeJbNbZ28q5mW KaLPDhjjOPUZzmuStgIcrcGdFLFyvaR7zXK+JPiBpOgM1uh+23i8GGI8If8AaboPp1rnviH45ngu JND0mUxsgxczqfmB/uKe3ufwrzKssNguZKdTbsaV8Vyvlge12HiPUtc8IJqOmW9rdXvmYubUnAVd xyoyeu3GM9a861qPTdW8a21vpenTWCzSxxz28sewh93Py9uK1/DMeiPodtPp2sRaPrkLj7RJNKQJ FBORtJwQRirmpa7oN78TNOvheQrbWcJ8256K7jO0A98ZFaU17KcuVPr/AF5+RE3zwjzPt/X+ZqeI 9H0e40jX7Wy0u1huNPiR1kiiAYZXf1HsDWN8PrLS38M3t9f2FvcmO7VA00YYgHaO/wBan0jxPpUn irxKby/iis75QsUjn5XABXj8DWPoerWFh8OtYsGvYlvZJi0MWfmfG3BH5UKFRU3DXeP47jcoOalp 1Oh0HQdMs9X1oXmn280bamltbrLGGCAjdgenDfpWRZaZozfFi7sb2GFLVWPkQEARl9q4GOnqcVs6 p4q0OS+0WS2v4dsl8Lm8IPEZEe3n9PyrnZrvw1qHxHvZ9UkWfTbjHlzKzBVfauCSOccEUU/aPmcr 6r/gBPkVkrbmh4za3ttJurTVfDsdpd+afsF3ZwgRFcjGW9cZyDVe/wBNsU+GmiXi2cK3MtzGskoQ bmBZsgnvWjq+q6dYeC9R0u412DV3nYiyRG3tGmRtBPPT1NVdOvNH13wLp2jzavb6fc2M6vIJ+NwV iePXINOLkoJ2dk/PsJpObXkP8U6Vp1t8R9Cs4LGCO3l2eZEkYCvlyOR3rT17Q9Ik1XTJbTTreJbX VEtrqNIwA6uARkdxyPzrC8ReI9Lv/iNpV9Bcq1nZtGsk/O3hiSR6gZrTtPFWif8ACZax9ov4/wCz roQTRTYOPMjA6cf5xUuNRRi9dF+v+Q04NtablMaDpl38XJdOe0jFnHGJBAq4QkIOw7ZOak1S5sNT 0nWIbnwy0P2aSRLO6s7Q7RsyMs46cjntVYeJ9KtvirJq5uQ9hLGI/OQEgZQDOOuMiuv03QJToetR 2upC5i1Z5Ht96lUiD57fU54pVJOHK5dl3+Y4RUuZR7v/AIB4kO3v6V6b8PPA08FxHrmrRGMpzbQM PmB/vsO3sPxrofDXw/0nw+UuHH228XpNKOFP+yvQfXrXVVOJxvMnCnt3HQwvK+aZ4P410a80jxLe Nco3lXUzSwy4+VwxzjPqM4xXP19I3lla6hbtb3lvHPC3VJFDCuQ1D4VaDdMXtHuLJj2jbco/Bv8A GtaOPhypTRnVwkr3ieOkA9RRXotx8H7oE/ZtYiYf9NYSP5Gqj/CXXVPyXli//AmH9K61i6D+0c7w 9VdDhaK7cfCfXyebmxH/AANv8Knj+EWrn/WalZL9Fc/0FH1qj/MH1er2OBor0qD4PP8A8vGtAe0c H+JrTtvhLosfNxeXk/sGVB+gqHjqC6lLC1X0PIuBTo43ncJFG0rHoqKWP6V7naeAPDFngrpUcrD+ KZi/8zW5bWVrZrttbaGBfSNAv8qwlmMV8MTaOCl1Z4bp/gfxJqWDFpckSH+O4IjH68/pXV6Z8InJ D6rqYA7x2y/+zH/CvTqK5J4+rLbQ3jhKcd9TD0jwdoOikPaWEZlH/LaX53/M9PwrcoorjlKUneTu dSioqyQUUUVIz//Z --_005_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=4649; creation-date="Fri, 26 Jul 2013 19:57:11 GMT"; modification-date="Fri, 26 Jul 2013 19:57:11 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABeAPQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0rxN4 ni8OQ22baS5uLqTy4YkIG4+5PTqPzpvh3xQNclvbeeylsrqyYLLHIwYd+hH0NZXxIl09LCyi1Szm kglm2i5ifabY8fN0OeM8d8Vi+HvEN5DoviOF71tQsbGA/ZrtgckkEAZP4VvGmnTvbUm+pvaJ8Q7b W9YgsEsZ4fPLiOV2Uq20E/0qXU/HdvpfiX+yJLOZiHjRplYbV34wcde9cPaQDR9O8F6lgjdcybz7 M4/pmrPiaA3PizxM6gl7a1inX6oYz/LNaeyhzeX/AAbCu7HXHx5b/wDCUjRRZTFjcfZ/P3Dbuxk8 de9M1fx6un6neWdppdxe/YUD3MiOFCDjoDyeorjbDdNrfhvUpBh9Q1K4nP0LqB/KrHi68sovE+oz RNcaNqtqgaOcPlbzgYG3HBI79OOaFSjzJW6fqF3Y7O+8a2tnY6RdpbTSx6o4RBwpTOOufrU9l4pi vdb1XTVtpFfTl3M5YYf6Vxvii9urzwz4V1TUYyjLcK9wwTAXkYJHbIGateFZ01HxV4q1C0JltJY8 JKAdrf5xU+zjy3/rcd9TT074k2moWGoXK2M8Zs4BP5bMuZFzg4PsauX3ja3stB07URZzSy6jgQWy kbiT2J6f/rrzWOJ7TwZZahGjYmFzYzYHZjuXP4g1u6vmDwl4MvJEb7PbSI0rhSQg4PP5GrdGF/mL mZ2nhzxXHr11eWUtnLZXtmR5sMjBsA+4roK4bwPqd3qfiPWHF7Ne6bHgQTSIFBJOeuB2/TFdzXPU jyysUmFFFFZjCiiigAooooAKKKKACiiigApM0E1k6r4i07R5kiv7jynkXco2McjOOwpqLk7JClKM VeTsauaXNcz/AMJ1of8Az/f+Qn/wrbtL2K8to54G3RSqGRsYyDTlCcfiViY1IT0i0y3S01TmnVJY UUUUAFFFFAGT4h1/SfD9kkutzLFbzP5a7oy4Y4zjAB9KwY/if4Lhi8uLUESP+6trIB+W2sb45/8A Itad/wBfn/sjVy3gL4aWfi/QH1C5v7m3dZ2i2RKpGAAc8j3oA9Hj+J3g6XCf2rEoHTfC4H6rXR6f qGn6tB9o0+5t7qJuC8TBh9DivNbn4E2hhb7LrVysuOPNiVl/HGDXnqSaz8N/FrqG8u6t2HmIrfu7 iM88+oI/EH3FAH0o4jjQuyqFjBOcdK46T4neCpyrS6hHIV+6WtZDj6fLXSxX0Wp+H1vrc5iuLbzU z6Fc184eC9Ai8T+JbXSp5pIY5kcl4wCw2qT3+lAHtrfFPwdIpR9UVlbghreQj/0GtTRfF3hvVnFt pOpWbuekKnYx+inBNcZ/worTP+gvff8AfCf4Vxnjj4Z3XhC2S/guvtljvCs+3ZJEx6E47Z7jvQB9 BbVxjAx6YrC1/wAY6D4cuI7TWLsQSSx71QxM4K5x2BHUVz/wk8W3HiHRJ7PUJDLeWBVfNY/NJGfu k+pGCM/SuN+OX/I1af8A9eX/ALO1AHs+mXdrf6dBd2DK1rOgkjZV2gqehxWTrfjnQPDt+LPVb7yL goJNnlO3ynODkAjsaPAX/Ih6J/16R/yryT40f8j0n/XnH/6E9AHuWn6hbarYQ3tjMs1tOu+ORehF Wa8O+EXjP+ydS/sK+kxZ3b5t2Y8Rynt9G/n9a9xoAoazrVj4f05r7U5/JtlYKX2luScDgAmq+geK NJ8Txzvo919oWAhZDsZdpPI6gVznxi/5J9cf9d4v/QhWF8CP+PHWv+u0X/oJoA6qb4o+E4J5IZNU w8bFGHkScEHB/hpn/C1vCH/QV/8AJeT/AOJrDuvgjpt1dzTtq16plkaQgKmASc+nvXO+M/hVY+F/ DFzqkGo3U0kJQBJFUKdzAdh70Ad9/wALW8If9BX/AMl5P/iaP+FreEP+gr/5Lyf/ABNeV/DvwHa+ NY9Qa6vJ7Y2rRhfKCnduDdcj2rs/+FFaZ/0F77/vhP8ACgD0mxvYNSsYLy0fzLedBJG+CNynkHB5 qeqWj6cmjaPZ6dHI0iWsSxK7YywAxk1Hf3qZaBZArD7wPf8AGgCxJcqUzEQwzgn0rzT4iyNJqloW OT5J/wDQjXaeaUGUPX8jXC+O5Vm1C0Zf+eJyPT5q6sF/GRxZj/u7+Ry9eleHdTmg0qzTh0ESjae1 ea13egNvtLVB0EYLGu7Gq8Vc87LHacvQ7+3mWVR2YDlfSrFYloWLqUOCO57VsLIGGQc15ElY91O5 JRSZopDFooooA8y+Of8AyLWnf9fn/sjVa+Cf/Ijy/wDX7J/6CtVfjn/yLWnf9fn/ALI1cD4V+Jeo eD9JbT7O0s5o2labdMW3ZIA7HpxQB9F14P8AGuWF/GsCRkeZHZoJcepZiP0NLdfHDXpoGSC2063c 9JArMR9ATisnw54P1zx5rJursXAtpX33N9MCNw7hc9TjgY4FAHsXgdXT4Y6YJAQ32LPPpg4/TFeQ fCT/AJKJpv8A1zl/9Fmvf3t4rTSGt4FCRQwFEUdlC4Ar5e0G71Oy1SGfRPO+3qreX5Me9sEc4GD2 zQB9WVxHxd1C3tPAV3BKy+bdukUSZ5JDBifwANeWXnjvxzYMqXt/e2zOCVE1sqEj2ytN0vwv4q+I U630krzw5KG8upflTB5AXr+AAoA6f4E20h1DWLnB8pYo48/7RJP8v51T+OX/ACNWn/8AXl/7O1er +FPDFp4S0SPT7MlznfLKww0rnqx/kB2Aryj45f8AI1af/wBeX/s7UAeo+Av+RD0T/r0j/lXkfxq4 8cL/ANeUf/oT1654C/5EPRP+vSP+VeR/Gv8A5Hdf+vKP/wBCegCh418Htoun6TrNmhFjfW0Rfb/y ymKAn6Buo98+1erfDLxn/wAJTofkXcgOp2YCTZPMi/wyfj39/rWpZaTa678P7HTr5N8Fxp8Kt6j5 Bgj3B5H0rwtG1P4a+N+QTNavgjotxCf6EfkR7UAet/GL/kn1x/13i/8AQhWF8CP+PHWv+u0X/oJr S+JuqW2tfCr+0LGTzLe4khdD/wACHB9weDWb8CP+PHWv+u0X/oJoA9XrjPi3/wAk7v8A/fi/9GLX Z1xnxb/5J3f/AO/F/wCjFoA5f4D/AOp1z/fh/k9etE15L8B/9Trn+/D/ACevWW6UAc74q8aad4QS 2bUluG+0lhH5KbuVxnPI9RXByfFHRZHZ2W9LMcn9yP8AGrPxjVZbzw0kihka6ZWB6EExgisDVLHS dWl1uw0TTYp9RtIpQDb2vlAYnjCqq5O5lXeC3GQaANA/E3SUOYftgB6qYhj+dZeo+JrPxHdo1rvV o0wVcYJ56ioR4ejghF1caXGbYaPEhL4RWvPNVWTd2kPzA9xyaqeM7CSDUtNksrFLOS5LiG0jthDO hDYCsqkhhzhXH3hnNa0avspqZjiKPtqbgWQMniuo0rWrextI43Em8AAkLmsuXQb/AEuyt5r9U8x1 HmGM5CN6H/OKr11TxdPFRUqTvHudOVZL7ODqVnq+i6HbweMdOhXGLgnudg5/WrUXj3TY87luce0Y /wAa8+pD901i4JnsLL6Pme2wziVFYdGAI/GrAOayNPcm3h/3F/lWqnQVzHivckooooEeZfHP/kWt O/6/P/ZGpPg7pOn33gyWW7sbWeQXki75YVY4wvGSKX45/wDItad/1+f+yNVr4J/8iPL/ANfsn/oK 0AdpHoWlQuHi0yyRh3W3QH+VXgMDA6ClooAgvP8Ajxn/AOubfyr58+En/JRNN/65y/8Aos19B3n/ AB4z/wDXNv5V8+fCT/komm/9c5f/AEWaAPYPiH4SXxZ4beKFR9vtsy2rHu2OV+jDj649K8r+FXi1 vDviE6besUsr5xGwfjypugJ9M/dP4ele/V4d8YfCH9maoNcs48Wl622cL/BL6/8AAv5g+tAHuNeH fHL/AJGrT/8Ary/9nau7+F/i/wD4Sbw8ILqTdqNiBHNk8yL/AAv+OMH3BrhPjl/yNWn/APXl/wCz tQB6j4C/5EPRP+vSP+VeR/Gv/kd1/wCvKP8A9CevXPAX/Ih6J/16R/yryP41/wDI7r/15R/+hPQB 7T4Z/wCRV0j/AK8of/QBXNfFDwZ/wk+ifa7OPOp2SlogBzKnVk/qPf610vhn/kVdI/68of8A0AVp 0AfLlt4huIfCt9oUmXtriVJo8n/VOrAt+BHb1H1r0z4Ef8eOtf8AXaL/ANBNYPxb8Gf2Nqn9tWMe LG9f96qjiKU/0br9c+ore+BH/HjrX/XaL/0E0Aer1xnxb/5J3f8A+/F/6MWuzrjPi3/yTu//AN+L /wBGLQBy/wAB/wDU65/vw/yevWW6V5N8B/8AU65/vw/yevWjQByfjHwXZ+L0tVvbi4h+ylinkled 2M5yD6VyD/B/SkPF/qH5p/8AE16uyZqCWAYyBUSbSuNHlD/CTTBx9tvyM5wSmP5VreGvBeneHrqW 5hMs9yRtWWYglB3C4HFdvLbgIcDms54/LbFePmlWX1dpM6aEVzojliSaJo5VDo4wynoRXIzeHkW4 kWJnKKxAGRkCuxqoLbNw7qOp5Fc2QVJKpOKeljrq1ZU0uVnNp4fhcf6yUHuOP8KuWfhCC6Lbppwo HUY6/lXSwWgkZRsDE9q17exS3j2oOM55r6dzZzyxVVL4iK0g8pEUdFAFaCDApqx4qQCszjHUUUUx GXrvhzTPEtrHb6tbefFE/mIu9lw2CM8Ediafoegad4csTZ6Vb+Rbs5kK72b5jjJySfQVo0UAFFFF ADXRZEZGGVYEEe1c7pHw/wDDug6jFf6bp/k3MQIR/NdsAjB4Jx0NdJRQAVU1PTLTWdOmsdQhWa2m G10ORnv1HIq3RQBz2i+BdB8PX/23SrNrefYULCZyCp7EE4PQVJrvgvQ/Et3Hc6tZefNGnlq3mOuF znHBHc1u0UAV9PsLfS7CCys4/Lt4EEcaZJwo6DJ5rH1vwLoHiO++2arY+fcbBHu811+UZwMAj1Nd BRQBFa20VnaQ20C7YYUWNFznCgYA/IVLRRQBV1LTbXV9Pmsb+FZraZdro3cVS0DwvpPhiOdNHtfs 6zsGkG9myRwOpNa9FABVHV9Hste02Sw1KHzraQgsm4rnByORz1FXqKAMfQPCukeGBONHtfs4uCpk /eM27GcdSfU1sUUUAJijFLRQBXniyvy4+lY12pWUAjHFbzDIqhdWqytuIOQPWvOx+DeIpOMNzejU UJXZk0+1hZpCRwM9anNpz3q1bwbcVzZZgKuFnKVS2q6GletGaSiWreFEywADN1NWcVHGMCpK9o5Q xS0UUCCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAEIpjJm pKSgCDyR6U9YwKkxRikMQDFOoopiCiiigAooooA//9k= --_005_1C6085AE4073A9448F7C718CC7EE1DEB10442CSEAMBX2seasamsung_-- --===============0643236701== 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 --===============0643236701==-- From ipp-bounces@pwg.org Mon Jul 29 05:31:25 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7221F9E34 for ; Mon, 29 Jul 2013 05:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n41nCP+txUGB for ; Mon, 29 Jul 2013 05:31:15 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25E21F8EDF for ; Mon, 29 Jul 2013 05:31:04 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 21AE390E3; Mon, 29 Jul 2013 12:34:56 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id 11BF690DA for ; Mon, 29 Jul 2013 12:34:55 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQP00NF66R35B61@mail-out.apple.com> for ipp@pwg.org; Mon, 29 Jul 2013 05:30:39 -0700 (PDT) X-AuditID: 11807158-b7f326d000001696-f8-51f6606e9f38 Received: from [17.153.97.63] (Unknown_Domain [17.153.97.63]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id B7.E0.05782.F6066F15; Mon, 29 Jul 2013 05:30:39 -0700 (PDT) From: Michael Sweet Date: Mon, 29 Jul 2013 08:30:47 -0400 To: "" Message-id: <36E7EF58-63A0-4B77-B366-83F98F6339EC@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiODPRXjc/4Vugwa+VehbH9r1ksTjyLdaB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgymj5XFWwS6Ti1ZVdbA2My4W6GDk5JARMJGau 2sQKYYtJXLi3nq2LkYtDSKCbSeLz3XPsIAk2ATWJ35P6wIqYBRIk9i98DWazCKhKrH63hRHE Fhawk7g65yoLiC0ioCjxc9p2sDivgI3Ezc+z2CFsPYml/+YAxTmAlslK7PydNIGRexaSqbOQ VEHE5SW2v53DPAuog1lAR2LyQqiwtsSyha+ZYeyP548wLWBkW8UoUJSak1hpqpdYUJCTqpec n7uJERRUDYUROxj/L7M6xCjAwajEw2vh+iVQiDWxrLgy9xCjBAezkgjvDa9vgUK8KYmVValF +fFFpTmpxYcYpTlYlMR5vTI/BAoJpCeWpGanphakFsFkmTg4pRoY65Yrn4kU+HGTf9qNSYJ3 yplWqj0KOJgjdEeb11B41rXMS3c2eKSbvnyQK+V84HHBtHV27MyBuqylpZc6a3u5rhdWVMhu y6+o+Bq4V6CP886iCfyn3zQrqc7+FpQS51PInV+Vpidx/ZEIm/lBlffiCR7tGi84r/FfmqQb ceRif/0Xd5viPZ1KLMUZiYZazEXFiQDr3ND7JgIAAA== Subject: [IPP] Draft F2F slides posted for review at today's concall X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1008550584==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1008550584== Content-type: multipart/alternative; boundary="Boundary_(ID_n7IWLEwXnrshnEeZX4G8xQ)" --Boundary_(ID_n7IWLEwXnrshnEeZX4G8xQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted the draft F2F slides to: ftp://ftp.pwg.org/pub/pwg/ipp/slides/ipp-wg-agenda-august-13d1.pdf For review at today's conference call... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_n7IWLEwXnrshnEeZX4G8xQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair
= --Boundary_(ID_n7IWLEwXnrshnEeZX4G8xQ)-- --===============1008550584== 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 --===============1008550584==-- From officefile01240@cantv.net Mon Jul 29 11:18:40 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FE811E810F for ; Mon, 29 Jul 2013 11:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.516 X-Spam-Level: *** X-Spam-Status: No, score=3.516 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 Rf6Nx-uepitj for ; Mon, 29 Jul 2013 11:18:32 -0700 (PDT) Received: from 10ibl20ser04.datacenter.cha.cantv.net (10ibl20ser04.datacenter.cha.cantv.net [200.11.173.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2311E80FF for ; Mon, 29 Jul 2013 11:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at cantv.net Received: from webmail-02.datacenter.cha.cantv.net (webmail-02.datacenter.cha.cantv.net [200.11.153.85]) (authenticated bits=0) by 10ibl20ser04.datacenter.cha.cantv.net (8.14.3/8.14.3/3.0) with ESMTP id r6TIFQSq003129; Mon, 29 Jul 2013 13:45:26 -0430 X-Matched-Lists: [] Received: from 81.91.228.125 ([81.91.228.125]) by webmail-02.datacenter.cha.cantv.net (Cantv Webmail) with HTTP; Mon, 29 Jul 2013 13:45:26 -0430 (VET) Date: Mon, 29 Jul 2013 13:45:26 -0430 (VET) From: "Dr.Nnaluo Edwin." Reply-To: chukwumercy2011@hotmail.fr To: offeoffe363@yahoo.com Message-ID: <215314012.2215074.1375121726539.JavaMail.gess@webmail-02.datacenter.cha.cantv.net> Subject: Re: RECEIVE YOUR REWARD MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: Cantv Webmail X-Originating-IP: [81.91.228.125]  
Hello

I have instructed my secretary Mr.Chukwu Mercy to release some funds in a Cashier Cheque to you.Write him through his Email:(chukwumercy2011@hotmail.fr) and forward your details to him.

1. Full Name:.........
2. Country:........
3. Delivery Address:..........
4. Telephone:........../Occupation...........
5. Your Age....../Sex..........
Thanks
Dr.Nnaluo Edwin.
From ipp-bounces@pwg.org Mon Jul 29 13:38:18 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2D421E80B1 for ; Mon, 29 Jul 2013 13:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOCjg0Qe-czs for ; Mon, 29 Jul 2013 13:37:59 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id C56E921E80B9 for ; Mon, 29 Jul 2013 13:37:52 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 5ADCF968C; Mon, 29 Jul 2013 20:41:44 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id CB15D94E7; Mon, 29 Jul 2013 20:41:41 +0000 (UTC) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQP00G8FTAWR1N1@mail-out.apple.com>; Mon, 29 Jul 2013 13:37:44 -0700 (PDT) X-AuditID: 11807143-b7fb46d00000227e-79-51f6d296f069 Received: from [17.153.97.63] (Unknown_Domain [17.153.97.63]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 94.A0.08830.792D6F15; Mon, 29 Jul 2013 13:37:44 -0700 (PDT) From: Michael Sweet Message-id: <0B5647B7-A89E-4D82-8571-16E9E0A23389@apple.com> Date: Mon, 29 Jul 2013 16:37:58 -0400 To: "cloud@pwg.org" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiODPRXnfGpW+BBlMbWS0ubz/AanFs30sW iyPfYh2YPbae/MHmMW/xdKYApigum5TUnMyy1CJ9uwSujL1vHjAXzJaomDi9j7mBca1oFyMn h4SAicSMv/9ZIWwxiQv31rN1MXJxCAl0M0k0nT/PApJgE1CT+D2pD6yIWSBBYnHPMqA4Bwev gI3ExsWlIGFeAT2Jpf/mMILYLAKqEnOOXAArFwYqaZu2nR2iVVFi2fQ/YHERAWWJN42NrCBj JARkJXb+TprAyDMLyYJZSKZCxLUlli18zTwLqINZQEdi8kI0YQj74/kjTAsY2VYxChSl5iRW GuklFhTkpOol5+duYgSFXUOh8w7GY8usDjEKcDAq8fBuKPgWKMSaWFZcmXuIUYKDWUmE9+IM oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFej8wPgUIC6YklqdmpqQWpRTBZJg5OqQZGh/kr3xdX HQ38LLVnws2MG4d/ycwPiCivf/k54KX6gznecw0M2YW5pI9d3fSu1MrtfEG5QZ8VV+9hN+tf Le9WtpQwz1r8/lvigj6TW4GVT4pZhWpTTnQk1x5V3PNEdK0aX+TdiCsZXy/+15F+qlnUeuTM iXfnPp/m+fj45535/RzuhvryL8TqlViKMxINtZiLihMBICA1ujcCAAA= Cc: "" Subject: [IPP] Minutes posted from today's joint Cloud/IPP meeting X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1099894836==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1099894836== Content-type: multipart/alternative; boundary="Boundary_(ID_I39vcGPYYJVTI/MaW3IhIg)" --Boundary_(ID_I39vcGPYYJVTI/MaW3IhIg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted the minutes from today's joint Cloud/IPP meeting to: ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20130729.pdf Our next conference call is August 26, 2013 at 3pm ET. Cloud F2F meeting is NEXT WEEK on August 7, 2013 at 1:30pm PT. Action items: - Mike to send CopyInput ticket slides to Daniel for SM meeting in the morning (DONE) - Mike to confirm scope of trademark registrations and get the new logos registered _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_I39vcGPYYJVTI/MaW3IhIg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20= 130729.pdf

Our next conference call is = August 26, 2013 at 3pm ET.  Cloud F2F meeting is NEXT WEEK on = August 7, 2013 at 1:30pm PT.

Action = items:

- Mike to send CopyInput = ticket slides to Daniel for SM meeting in the morning = (DONE)
- Mike to confirm scope of = trademark registrations and get the new logos = registered


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

= --Boundary_(ID_I39vcGPYYJVTI/MaW3IhIg)-- --===============1099894836== 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 --===============1099894836==-- From ipp-bounces@pwg.org Tue Jul 30 09:12:32 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D29121E80DB for ; Tue, 30 Jul 2013 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 240evcOQkX0t for ; Tue, 30 Jul 2013 09:12:25 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7A21F944C for ; Tue, 30 Jul 2013 09:12:25 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 6635A9768; Tue, 30 Jul 2013 16:16:22 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by www.pwg.org (Postfix) with ESMTPS id 915BF95A7 for ; Tue, 30 Jul 2013 16:16:21 +0000 (UTC) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQR00JSJBOLHQH1@mail-out.apple.com> for ipp@pwg.org; Tue, 30 Jul 2013 09:12:21 -0700 (PDT) X-AuditID: 11807158-b7f326d000001696-0c-51f7e5e39c3c Received: from [17.153.97.63] (Unknown_Domain [17.153.97.63]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id C6.0C.05782.4E5E7F15; Tue, 30 Jul 2013 09:12:21 -0700 (PDT) From: Michael Sweet Date: Tue, 30 Jul 2013 12:12:20 -0400 To: "" Message-id: <821E1223-24ED-4383-BBE9-E0CD20EE14AC@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiODPRXvfp0++BBn8eiVoc2/eSxeLIt1gH Jo+tJ3+wecxbPJ0pgCmKyyYlNSezLLVI3y6BK2PxhSlsBYekKv6cncfUwNgk0cXIySEhYCLx aMVxRghbTOLCvfVsXYxcHEIC3UwS95adZgNJsAmoSfye1McKYjMLJEh0HngA1sAioCqx680h MFtYwE5iV/NVsBoRAUWJn9O2g8V5BWwkFk5+zwxh60ks/TcHKM4BtExWYufvpAmM3LOQTJ2F pAoiri2xbOFr5llAHcwCOhKTF6IJQ9gfzx9hWsDItopRoCg1J7HSVC+xoCAnVS85P3cTIyis GgojdjD+X2Z1iFGAg1GJh9fhwvdAIdbEsuLK3EOMEhzMSiK85ycChXhTEiurUovy44tKc1KL DzFKc7AoifN6ZX4IFBJITyxJzU5NLUgtgskycXBKNTDusXi05vsSXcPz6SonnzPxiczPX8ss XiArbZTuMs/0Xdv7uJ/hbybMkgxe0HYj8ticmqc9QslnHU6ce9igNEU/k7Ug/UBK5tffYaor mFy3hun9i1ssfm7ebiYHj0NJ4hezen9psj+JMGqOn6qvslmsNclab/35m0tsuaY0rZXfxLcg +HvzgiolluKMREMt5qLiRAAANggmJwIAAA== Subject: [IPP] Updated stable draft of the IPP FaxOut Service posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0339150798==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0339150798== Content-type: multipart/alternative; boundary="Boundary_(ID_cOLRd3DuE94ZGzYqiYvuNw)" --Boundary_(ID_cOLRd3DuE94ZGzYqiYvuNw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted an updated stable draft of the IPP FaxOut Service specification to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130730.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130730.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130730-rev.pdf along with the summary of last call comments: ftp://ftp.pwg.org/pub/pwg/ipp/wd/lcrc-ippfaxout10.txt For discussion at next week's IPP meeting on Thursday, August 8. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_cOLRd3DuE94ZGzYqiYvuNw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable ftp= ://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130730.docx= =

along with the summary of last call = comments:


<= div>For discussion at next week's IPP meeting on Thursday, August = 8.

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

= --Boundary_(ID_cOLRd3DuE94ZGzYqiYvuNw)-- --===============0339150798== 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 --===============0339150798==-- From pwg-announce-bounces@pwg.org Tue Jul 30 10:46:56 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8711E821D for ; Tue, 30 Jul 2013 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+cT+xVVOZr5 for ; Tue, 30 Jul 2013 10:46:51 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7C11E810B for ; Tue, 30 Jul 2013 10:46:51 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 1B59A97BA; Tue, 30 Jul 2013 17:50:48 +0000 (UTC) X-Original-To: pwg-announce@pwg.org Delivered-To: pwg-announce@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id 94035977A for ; Tue, 30 Jul 2013 17:50:46 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQR008GNG1O1CN0@mail-out.apple.com> for pwg-announce@pwg.org; Tue, 30 Jul 2013 10:46:46 -0700 (PDT) X-AuditID: 11807153-b7fd26d000007d21-01-51f7fc0466ae Received: from [17.153.107.123] (Unknown_Domain [17.153.107.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id E4.83.32033.50CF7F15; Tue, 30 Jul 2013 10:46:45 -0700 (PDT) From: Michael Sweet Date: Tue, 30 Jul 2013 13:46:45 -0400 To: "PWG Announcements Inc." Message-id: X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiODO7Wpf1z/dAg1N7LC2OfIu1WNe6mtmB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgymjc8Yq14KJ1RdvO1cwNjIeNuxg5OSQETCR2 /p/PBGGLSVy4t56ti5GLQ0ign0niw7vN7CAJNgE1id+T+lhBbGaBBImGhQdZQGwWAVWJrx1r GUFsYYEoibarD8BqRASMJXa072UDsXkFbCRuTf7BDmHrSSz9NweongNomazEzt9JExi5ZyGZ OgtJFURcW2LZwtfMs4A6mAV0JCYvRBOGsD+eP8K0gJFtFaNAUWpOYqWxXmJBQU6qXnJ+7iZG UFg1FAbvYPyzzOoQowAHoxIPr8OF74FCrIllxZW5hxglOJiVRHjPTwQK8aYkVlalFuXHF5Xm pBYfYpTmYFES553xBSglkJ5YkpqdmlqQWgSTZeLglGpgbGYX3Vc1MTba46xzudXLeVMkbBmV hETem09QnCp6QLfqYkpXNO+v3K5ZKxfeP8paY6ozvXpJdHFTs9vz1slWYm3MhwT75Ve/rRWR Pcr598uFNNajjUda1p450N9fvuAn1weGHpHE7Jx+z+redTGbbzcJhc/ZMP9UnuCr518WMLsZ 8+1PeCytxFKckWioxVxUnAgAdcgeGicCAAA= Subject: [Pwg-Announce] PWG Last Call of IPP Transaction-Based Printing Extensions (07/30/13 to 08/30/13) X-BeenThere: pwg-announce@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Printer Working Group Announcement List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0041489928==" Sender: pwg-announce-bounces@pwg.org Errors-To: pwg-announce-bounces@pwg.org --===============0041489928== Content-type: multipart/alternative; boundary="Boundary_(ID_uW3nEAEm/onYOq9eCUP3GQ)" --Boundary_(ID_uW3nEAEm/onYOq9eCUP3GQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, [This PWG Last Call starts today, Tuesday July 30, 2013, and ends Friday, August 30, 2013 at 10pm US PST.] This is the formal announcement of the PWG Last Call for the IPP Transaction-Based Printing Extensions specification, located at: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf All required attributes and values defined in this document have been prototyped by Apple and/or other vendors. The IPP WG has completed extensive review of the various revisions of this document and an IPP WG last call. The PWG Process/3.0 requires that a quorum (30%) of PWG members must acknowledge a PWG Last Call (with or without comments), before any document can progress to PWG Formal Vote. This PWG Last Call is NOT a Formal Vote but it DOES require your review acknowledgment. HOW TO RESPOND Send an email with *exactly* the following subject line format: Subject: has reviewed the IPP Transaction-Based Printing Extensions specification and has [no] comments WHERE TO SEND YOUR RESPONSE Please send your response to *all* of the following email addresses (replacing "dot" with '.' and "at" with '@'): ipp "at" pwg "dot" org (IPP WG mailing list - you must be subscribed!) blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP WG Co-Chair) ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair) msweet "at" apple "dot" com (Michael Sweet, IPP WG Secretary and IPP Transaction-Based Printing Extensions Editor) Note that you must be subscribed to the IPP WG mailing list to send email there - otherwise your email will be silently discarded. Please do NOT simply reply to this note on the PWG-Announce list. Note: The PWG Definition of the Standards Development Process Version 3.0 is located at: http://www.pwg.org/chair/membership_docs/pwg-process30.pdf _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_uW3nEAEm/onYOq9eCUP3GQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable ftp:/= /ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrans10-20130708.pdf

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

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


HOW TO RESPOND

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

WHERE TO SEND YOUR RESPONSE

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

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

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

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

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

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

= --Boundary_(ID_uW3nEAEm/onYOq9eCUP3GQ)-- --===============0041489928== 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 --===============0041489928==-- From ipp-bounces@pwg.org Tue Jul 30 10:48:50 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4CE21E8095 for ; Tue, 30 Jul 2013 10:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JopURdPT6QLX for ; Tue, 30 Jul 2013 10:48:44 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id AF5DE21E80A7 for ; Tue, 30 Jul 2013 10:48:44 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 156A197FC; Tue, 30 Jul 2013 17:52:44 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by www.pwg.org (Postfix) with ESMTPS id C71C697F0 for ; Tue, 30 Jul 2013 17:52:41 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQR00BKCG4W6GL0@mail-out.apple.com> for ipp@pwg.org; Tue, 30 Jul 2013 10:48:41 -0700 (PDT) X-AuditID: 11807166-b7f9f6d000005fde-9c-51f7fc78447b Received: from [17.153.107.123] (Unknown_Domain [17.153.107.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 3B.53.24542.87CF7F15; Tue, 30 Jul 2013 10:48:41 -0700 (PDT) From: Michael Sweet Date: Tue, 30 Jul 2013 13:48:41 -0400 To: "" , Ira McDonald , Paul Tykodi , Michael Sweet Message-id: X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiODO7Wrfyz/dAgydvFSxev1rKbnFs30sW iyPfYi06v1k7sHhsPfmDzWPnrLvsHvMWT2fy2HzlOUsASxSXTUpqTmZZapG+XQJXxvZvvawF X3krulveMDcwXuTpYuTgkBAwkVhw2rKLkRPIFJO4cG89G4gtJNDPJPFkaSyIzSagJvF7Uh8r iM0skCCxedItFpBWFgFViWnro0HCwgIZEjeu3WXuYuTiEBGYzCjRereXGSTBK2AjcXjtPiYI W09i6b85jBBrZSV2/k6awMg9C8nUWUiqIOLyEtvfzmGeBdTBLKAjMXkhmjCIrS3x8fwRpgWM bKsYBYpScxIrLfQSCwpyUvWS83M3MYICr6EwbQdj03KrQ4wCHIxKPLwOF74HCrEmlhVX5h5i lOBgVhLhPT8RKMSbklhZlVqUH19UmpNafIhRmoNFSZx31heglEB6YklqdmpqQWoRTJaJg1Oq gXHSwlnMVm1yH29vUL2642yoQajO5Ll+Hga3U5We5Nu/7grwPTI3o/GB59V/Fv4fhKYxBeU+ yjp9e4P65St1fadUOdsMbxiuuRDSJlg/70Ht3cK66wz8c6vnHbtxe5vA4VaJmJWrOjx+6bPV xnm/2DYx03/nofJPe4/FfPI8pt66P+qpA9fR0B9KLMUZiYZazEXFiQAdTH3fOAIAAA== Subject: [IPP] Apple has reviewed the IPP Transaction-Based Printing Extensions specification and has comments X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484437340==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0484437340== Content-type: multipart/alternative; boundary="Boundary_(ID_uVNu9hT0a4rD+7gpb6mTYw)" --Boundary_(ID_uVNu9hT0a4rD+7gpb6mTYw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT One comment from the July 8, 2013 conference call: - Section 9.2, line 753: bad/broken reference _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_uVNu9hT0a4rD+7gpb6mTYw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT
One comment from the July 8, 2013 conference call:

- Section 9.2, line 753: bad/broken reference

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--Boundary_(ID_uVNu9hT0a4rD+7gpb6mTYw)-- --===============0484437340== 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 --===============0484437340==-- From ipp-bounces@pwg.org Tue Jul 30 14:44:04 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2580211E814B for ; Tue, 30 Jul 2013 14:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40wgXpT46yUu for ; Tue, 30 Jul 2013 14:43:58 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id B536111E8152 for ; Tue, 30 Jul 2013 14:43:58 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id E8D849471; Tue, 30 Jul 2013 21:47:57 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by www.pwg.org (Postfix) with ESMTPS id 012B4929D for ; Tue, 30 Jul 2013 21:47:55 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQR00FK7QZODUT1@mail-out.apple.com> for ipp@pwg.org; Tue, 30 Jul 2013 14:43:40 -0700 (PDT) X-AuditID: 11807153-b7fd26d000007d21-81-51f8338be100 Received: from [17.153.107.123] (Unknown_Domain [17.153.107.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 03.F3.32033.C8338F15; Tue, 30 Jul 2013 14:43:40 -0700 (PDT) From: Michael Sweet Date: Tue, 30 Jul 2013 17:43:39 -0400 To: "" Message-id: X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiODO7WrfH+Eegwf0phhbH9r1ksTjyLdaB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgyliyaCt7wUWxiq83LrM2MB4S6WLk5JAQMJFY fWQqM4QtJnHh3nq2LkYuDiGBfiaJ5ROXsoMk2ATUJH5P6mMFsZkFEiSe/LjJBGKzCKhKbL41 kbGLkYNDWCBcorONByQsIqAo8XPadkYQm1fARuLulbvsELaexNJ/c8DKJQRkJXb+TprAyD0L ydBZSKog4toSyxa+Zp4F1MEsoCMxeSGaMIT98fwRpgWMbKsYBYpScxIrjfUSCwpyUvWS83M3 MYKCqqEweAfjn2VWhxgFOBiVeHgdLnwPFGJNLCuuzD3EKMHBrCTCe34iUIg3JbGyKrUoP76o NCe1+BCjNAeLkjjvjC9AKYH0xJLU7NTUgtQimCwTB6dUA+NKj5oPCd4BJp9c4/Xvud+t8X7P Lct3yvkqy6PPE+ZePVd8Wfv33y9Lsmc/62KNm6uoaXXMNtvuSZDR9CnW2YeXrNeJsg9p958q 3+u+8OGqmQtKPv7b3haZsPTjNtcj32KyXWZuW3Dl8+XKT072q66kC9u4t7z52cXill2v4F+a UrJr+8aQw4uVWIozEg21mIuKEwHNrJzSJgIAAA== Subject: [IPP] Updated interim draft posted for IPP Shared Infrastructure Extensions (IPPSIX) X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0568127907==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0568127907== Content-type: multipart/alternative; boundary="Boundary_(ID_UyqIL6GzpD6IWnmXChtxSQ)" --Boundary_(ID_UyqIL6GzpD6IWnmXChtxSQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted a new interim draft of IPP Shared Infrastructure Extensions (IPPSIX) to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730-rev.pdf For review at the face-to-face... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_UyqIL6GzpD6IWnmXChtxSQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable ftp://= ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130730.docx=

For review at the = face-to-face...

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

= --Boundary_(ID_UyqIL6GzpD6IWnmXChtxSQ)-- --===============0568127907== 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 --===============0568127907==-- From ipp-bounces@pwg.org Wed Jul 31 11:47:07 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09C21F8F09 for ; Wed, 31 Jul 2013 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKxJtdF3Rerk for ; Wed, 31 Jul 2013 11:47:02 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 89F1321F8F24 for ; Wed, 31 Jul 2013 11:47:02 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 0496A8D9A; Wed, 31 Jul 2013 18:51:05 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by www.pwg.org (Postfix) with ESMTPS id 9B5FD8D65 for ; Wed, 31 Jul 2013 18:51:02 +0000 (UTC) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQT00D9XDH23P80@mail-out.apple.com> for ipp@pwg.org; Wed, 31 Jul 2013 11:46:57 -0700 (PDT) X-AuditID: 11807166-b7f9f6d000005fde-a7-51f95b9f52e2 Received: from [17.153.107.123] (Unknown_Domain [17.153.107.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 3B.E8.24542.0AB59F15; Wed, 31 Jul 2013 11:46:57 -0700 (PDT) From: Michael Sweet Date: Wed, 31 Jul 2013 14:46:56 -0400 To: "" Message-id: <228E1B57-9AB0-4221-B970-36700DA500BD@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUiODO7Wndh9M9Ag8lrRS2O7XvJYnHkW6wD k8fWkz/YPOYtns4UwBTFZZOSmpNZllqkb5fAlfFx0z3mgjWCFS9PXWZuYLzO38XIySEhYCLR +q+BEcIWk7hwbz0biC0k0M8k8fe/F4jNJqAm8XtSH2sXIwcHs0CCxMpWd5Awi4CqxIfnN9lB bGEg+920NywgtoiAosTPadvBRvIK2Eh86ZzJDGHrSSz9N4cRZIyEgKzEzt9JExi5ZyEMnYWk CMRmFtCWWLbwNTNEiY7E5IVQYXmJ7W/nMMOUfDx/hGkBI9sqRoGi1JzESgu9xIKCnFS95Pzc TYyggGooTNvB2LTc6hCjAAejEg+vw4XvgUKsiWXFlbmHGCU4mJVEeG9b/AwU4k1JrKxKLcqP LyrNSS0+xCjNwaIkzjvrC1C1QHpiSWp2ampBahFMlomDU6qBsSJjzRXJXNWvGZZ9vWEOrAbh Qr2eqdtDpqs6Psp9vTI4ZS1z8qMvvc92CX4SD+N+dyCTbab8ta5l5sFqu2Uv5dZ4tG9Vj+ja cLjgQ8gsRp1jASbKk3eY/eYOymhPDr080fOTTGPI8zbbqJcOrFWm51+n+UmcCZN/Notnx/MH E5ou7hD/YNGqxFKckWioxVxUnAgABplS3CQCAAA= Subject: [IPP] July 2013 release of ipptool X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1181388435==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1181388435== Content-type: multipart/alternative; boundary="Boundary_(ID_ZXbo14y3K/ClSXYmzIicZw)" --Boundary_(ID_ZXbo14y3K/ClSXYmzIicZw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, The July 2013 release of ipptool is now available on cups.org at: http://www.cups.org/software.php The release includes the new ippfind tool, improves timeout handling, and fixes several test files that used old STATUS names. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_ZXbo14y3K/ClSXYmzIicZw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

The July 2013 release of ipptool is now available on cups.org at:


The release includes the new ippfind tool, improves timeout handling, and fixes several test files that used old STATUS names.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--Boundary_(ID_ZXbo14y3K/ClSXYmzIicZw)-- --===============1181388435== 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 --===============1181388435==-- From ipp-bounces@pwg.org Wed Jul 31 13:03:01 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1121421F9FDA for ; Wed, 31 Jul 2013 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5nTurqdnfeM for ; Wed, 31 Jul 2013 13:02:55 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4F721F9CA4 for ; Wed, 31 Jul 2013 13:02:55 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 67BCA87A4; Wed, 31 Jul 2013 20:06:59 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by www.pwg.org (Postfix) with ESMTPS id 15495879D for ; Wed, 31 Jul 2013 20:06:57 +0000 (UTC) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQT00DBBH0E3PH0@mail-out.apple.com> for ipp@pwg.org; Wed, 31 Jul 2013 13:02:46 -0700 (PDT) X-AuditID: 11807153-b7fd26d000007d21-45-51f96d65b035 Received: from [17.153.107.123] (Unknown_Domain [17.153.107.123]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 14.8D.32033.56D69F15; Wed, 31 Jul 2013 13:02:46 -0700 (PDT) From: Michael Sweet Date: Wed, 31 Jul 2013 16:02:44 -0400 To: "" Message-id: <1D6A1EFC-482E-4704-AE2C-7C99E476F56C@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiODO7Wjct92egwfFfQhbH9r1ksTjyLdaB yWPryR9sHvMWT2cKYIrisklJzcksSy3St0vgyti4eiFzwRORil1t35kaGKcKdzFyckgImEj8 3L+KBcIWk7hwbz1bFyMXh5BAP5PEn20bWUESbAJqEr8n9YHZzAIJEn/PXmMEsVkEVCVmNr8B sjk4hAV8JbZPlgAJiwgoSvycth2shFfARuLI9+UsELaexNJ/c8DKJQRkJXb+TprAyD0LydBZ SKog4toSyxa+Zp4F1MEsoCMxeSFUWF5i+9s5zDAlH88fYVrAyLaKUaAoNSex0lgvsaAgJ1Uv OT93EyMoqBoKg3cw/llmdYhRgINRiYfX4cL3QCHWxLLiytxDjBIczEoivFvTfwYK8aYkVlal FuXHF5XmpBYfYpTmYFES553xBahaID2xJDU7NbUgtQgmy8TBKdXAKNJ/1MZyhciVYw1vTW/t DHY/xWTJnTzL6+PKml7f2+cFNa8/ePy6/mjFhMYV7p9dzP8yrwkz8nL/HGe10TmmfvdV/vyN dm0fHuqwSH3aKC3xtsJd/35dwttHCmembKlKT2ll2vw7ZEeajpb4I2d7tuXPztQvVVTax7vf 4mmVl77VIZH8kIhAJZbijERDLeai4kQA0RG0yiYCAAA= Subject: [IPP] Interim draft of IPP Everywhere Self-Certification Manual 1.0 posted X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0929414260==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============0929414260== Content-type: multipart/alternative; boundary="Boundary_(ID_C1zvyWR/SpHxnT6B6GWTAg)" --Boundary_(ID_C1zvyWR/SpHxnT6B6GWTAg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, I have posted a new interim draft of the IPP Everywhere Self-Certification Manual to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731.docx ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731.pdf ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippeveselfcert10-20130731-rev.pdf For review at the F2F. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_C1zvyWR/SpHxnT6B6GWTAg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All,

I have posted a new interim draft of the IPP Everywhere Self-Certification Manual to:


For review at the F2F.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--Boundary_(ID_C1zvyWR/SpHxnT6B6GWTAg)-- --===============0929414260== 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 --===============0929414260==-- From ipp-bounces@pwg.org Wed Jul 31 13:27:44 2013 Return-Path: X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717B921F9B92 for ; Wed, 31 Jul 2013 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qOy68mabG5u for ; Wed, 31 Jul 2013 13:27:40 -0700 (PDT) Received: from www.pwg.org (li433-199.members.linode.com [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 3732B21F8A50 for ; Wed, 31 Jul 2013 13:27:40 -0700 (PDT) Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 26C3E8E03; Wed, 31 Jul 2013 20:31:44 +0000 (UTC) X-Original-To: ipp@pwg.org Delivered-To: ipp@pwg.org Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by www.pwg.org (Postfix) with ESMTPS id C65E18DFA for ; Wed, 31 Jul 2013 20:31:42 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so2567807oag.1 for ; Wed, 31 Jul 2013 13:27:36 -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=Zi9cf3YvnoHeE0/C5pN3X3/0bUPQhoewNiF7sZPzcqU=; b=cXbD9KS+iZ9wpgOw3sBscJga0tAXxt+cHTUueMTO0gyXrka45sbFPo8W7z06FrXdxK nUIGZwqlGQ8LQ0QCui8vQwdYV3QxhvJpaUFOQMNrtuwXSd5jiOBGvyGvcsJV71Z9MH92 CqahHURYJvexm51FHwWNWF/BXmcNT2EEtZ4nR2ltvLxnAuDnTW67R4flp29OQKlfzGcu GvF9xetm+A+t8luoEkahFjyL67MRGR/dXdC5N3ZNDpOh6ebSMOEoc+6B8p2qx5V7pxiv 9z2ef4MSPSIUJjIP2flbzb3Z5A69Ucv/70UDvsxlzjQ3rBp85os7vGli518mBPULtEct ctlg== MIME-Version: 1.0 X-Received: by 10.43.82.198 with SMTP id ad6mr1101371icc.114.1375302456764; Wed, 31 Jul 2013 13:27:36 -0700 (PDT) Received: by 10.50.13.137 with HTTP; Wed, 31 Jul 2013 13:27:36 -0700 (PDT) Date: Wed, 31 Jul 2013 16:27:36 -0400 Message-ID: From: Ira McDonald To: "ipp@pwg.org" , Ira McDonald Subject: [IPP] Fwd: IETF HTTP-Auth WG Summary X-BeenThere: ipp@pwg.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Printing Protocol \(current\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1345305139==" Sender: ipp-bounces@pwg.org Errors-To: ipp-bounces@pwg.org --===============1345305139== Content-Type: multipart/alternative; boundary=bcaec518647664eebc04e2d48eaa --bcaec518647664eebc04e2d48eaa Content-Type: text/plain; charset=ISO-8859-1 Hi, FYI - IETF HTTP Basic and Digest are being updated and will be done in a few months. Cheers, - Ira ---------- Forwarded message ---------- From: Yoav Nir Date: Wed, Jul 31, 2013 at 12:09 PM Subject: [saag] HTTP-Auth WG Summary To: "saag@ietf.org" Hi The HTTP-Auth met today, Wednesday at 13:00 for 2 hours. The standard-track documents for updating Basic and Digest authentication are progressing nicely with little contention. They should be done in a few months. Of the four experimental protocols, one is at version -01 and has received a moderate amount of discussion, two are at version -00 and have received no discussion from this group, and one has yet to be submitted. Matt & Yoav _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --bcaec518647664eebc04e2d48eaa Content-Type: text/html; charset=ISO-8859-1
Hi,

FYI - IETF HTTP Basic and Digest are being updated and will
be done in a few months.

Cheers,
- Ira


---------- Forwarded message ----------
From: Yoav Nir <ynir@checkpoint.com>
Date: Wed, Jul 31, 2013 at 12:09 PM
Subject: [saag] HTTP-Auth WG Summary
To: "saag@ietf.org" <saag@ietf.org>


Hi

The HTTP-Auth met today, Wednesday at 13:00 for 2 hours.

The standard-track documents for updating Basic and Digest authentication are progressing nicely with little contention. They should be done in a few months.

Of the four experimental protocols, one is at version -01 and has received a moderate amount of discussion, two are at version -00 and have received no discussion from this group, and one has yet to be submitted.

Matt & Yoav
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--bcaec518647664eebc04e2d48eaa-- --===============1345305139== 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 --===============1345305139==--