attachment-0001

<div dir="ltr"><div><div><div><div>Hi Daniel,<br><br></div>But the same set of FaxModem subunit alerts (Printer MIB and IPP) MAY be used<br></div>by either FaxOut or FaxIn or both - implementation choice.<br><br></div>Cheers,<br>
</div>- Ira<br><br></div><div class="gmail_extra"><br clear="all"><div>Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>
Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<br>Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>
<div></div><div></div><div></div><div></div></div>
<br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel <span dir="ltr">&lt;<a href="mailto:Daniel.Manchala@xerox.com" target="_blank">Daniel.Manchala@xerox.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mike,<br>
<br>
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).<br>

<br>
Daniel.<br>
________________________________________<br>
From: Michael Sweet [<a href="mailto:msweet@apple.com">msweet@apple.com</a>]<br>
Sent: Tuesday, July 09, 2013 8:06 AM<br>
To: fx OHTAKE SHIN<br>
Cc: Manchala, Daniel; &#39;<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>&#39;<br>
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments<br>
<div class="HOEnZb"><div class="h5"><br>
Shin,<br>
<br>
On 2013-07-09, at 2:15 AM, fx OHTAKE SHIN &lt;<a href="mailto:shin.ohtake@fujixerox.co.jp">shin.ohtake@fujixerox.co.jp</a>&gt; wrote:<br>
&gt; Hi Mike-san,<br>
&gt;<br>
&gt; I&#39;ve returned to my office, so let&#39;s discuss again.<br>
&gt; My understanding may not be so enough because we&#39;ve past a week.<br>
&gt;<br>
&gt; We should discus with ITU-T.30 recommendations(facsimile protocols),<br>
&gt; instead of AT commands or PWG 5107.3.<br>
&gt; Because ITU-T.30 is the reference of FAX protocol,<br>
&gt; and in the world, there are too many facsimiles do not control by AT commands.<br>
&gt; CUPS is one of many IPP client implementations, also.<br>
<br>
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&#39;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...<br>

<br>
That said, we haven&#39;t made any of the new keywords required to support for IPP FaxOut. Like all &quot;feature&quot; keywords, the (implied) conditional requirement is that you use a standard keyword if you are reporting what that standard keyword represents, i.e., don&#39;t use a vendor keyword if a standard keyword exists.<br>

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