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