Subject: RE: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments

From: fx OHTAKE SHIN <[email-masked]>
Date: Tue, 9 Jul 2013 15:15:32 +0900

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:  [email-masked]
---------------------------------------------------------------------

> -----Original Message-----
> From: Michael Sweet [mailto:[email-masked]]
> Sent: Friday, June 28, 2013 10:22 AM
> To: Manchala, Daniel
> Cc: fx OHTAKE SHIN; [email-masked]'
> 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" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Michael Sweet
> > Sent: Thursday, June 27, 2013 5:07 AM
> > To: fx OHTAKE SHIN
> > Cc: [email-masked]
> > 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 <[email-masked]> 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
> > [email-masked]
> > https://www.pwg.org/mailman/listinfo/ipp
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Tue, 09 Jul 2013 11:06:34 -0400

Shin,

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

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

---

From: "Manchala, Daniel" <[email-masked]>
Date: Tue, 9 Jul 2013 18:56:31 +0000

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 [[email-masked]]
Sent: Tuesday, July 09, 2013 8:06 AM
To: fx OHTAKE SHIN
Cc: Manchala, Daniel; [email-masked]'
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments

Shin,

---

From: Ira McDonald <[email-masked]>
Date: Tue, 9 Jul 2013 16:14:38 -0400

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:[email-masked]
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
<[email-masked]>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.
> 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
> > //
> >>> 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
> >> 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
> >>> We still could have 'fax-modem-carrier-lost', but on the receiving
> device, and probably it is good to rename it
> >>> 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
> >>> But on the sending end we still need an indication that we lost the
> connection to the receiver.  Would changing
> >>>> detected by Called terminal. We think fax-modem-training-failure
> should be removed from the specification.
> >>> 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
> >>>> 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.
> >>>
> >>> 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
> >>> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> >>>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 09 Jul 2013 16:54:23 -0400

Daniel,

On Jul 9, 2013, at 2:56 PM, Manchala, Daniel <[email-masked]> 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.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Tue, 9 Jul 2013 21:02:09 +0000

Ira,

That's 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:[email-masked]]
Sent: Tuesday, July 09, 2013 1:15 PM
To: Manchala, Daniel
Cc: Michael Sweet; fx OHTAKE SHIN; [email-masked]
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

mailto:[email-masked]<mailto:[email-masked]>

On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

Daniel.
________________________________________
From: Michael Sweet [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 09, 2013 8:06 AM
To: fx OHTAKE SHIN
Cc: Manchala, Daniel; [email-masked]<mailto:[email-masked]>'
Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification and has comments

Shin,

>                phone: +81-45-755-5474<tel:%2B81-45-755-5474> (direct)
>                mail:  [email-masked]<mailto:[email-masked]>
>> From: Michael Sweet [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: fx OHTAKE SHIN; [email-masked]<mailto:[email-masked]>'
>> On 2013-06-27, at 8:26 PM, "Manchala, Daniel" <[email-masked]<mailto:[email-masked]>> wrote:
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>>> Michael Sweet
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN <[email-masked]<mailto:[email-masked]>> wrote:
>>>> Greetings,
>>>>
>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
ipp mailing list
[email-masked]<mailto:[email-masked]>
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Tue, 9 Jul 2013 17:15:16 -0400

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

On Tue, Jul 9, 2013 at 5:02 PM, Manchala, Daniel
<[email-masked]>wrote:

>  Ira,****
>
> ** **
>
> That’s 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:[email-masked]]
> *Sent:* Tuesday, July 09, 2013 1:15 PM
> *To:* Manchala, Daniel
> *Cc:* Michael Sweet; fx OHTAKE SHIN; [email-masked]
>
> *Subject:* Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification
> and has comments****
>
>  ** **
>
> Hi Daniel,****
>
> used****
> by either FaxOut or FaxIn or both - implementation choice.****
>
> Cheers,****
>
> - Ira****
>
>
> ****
>
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434****
>
> ** **
>
> On Tue, Jul 9, 2013 at 2:56 PM, Manchala, Daniel <
> [email-masked]> wrote:****
>
> Mike,
>
> Subject: Re: [IPP] Fuji Xerox has reviewed the IPP FaxOut specification
> and has comments****
>
>
> Shin,
>
> https://www.pwg.org/mailman/listinfo/ipp****
>
> ** **
>

---

From: fx OHTAKE SHIN <[email-masked]>
Date: Wed, 10 Jul 2013 17:42:51 +0900

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

> From: Manchala, Daniel [mailto:[email-masked]]
> Sent: Wednesday, July 10, 2013 3:57 AM
> To: Michael Sweet; fx OHTAKE SHIN
> Cc: [email-masked]'
> 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.
> > 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.
> 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.
> 
> >> 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.
> >>
> >> receiver and sender that I would not want to double things up.
> >>
> >>
> >> 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.
> >>>
> >> can trigger 'fax-out-modem-confirmation-not-received'.  This is how
> >> the sending end will indicate that it lost its connection to the receiver.
> >>>
> >> as 'fax-in-modem-carrier-lost' indicating that this is an error on
> >> the fax-in device. Likewise, we could have
> >>>> 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.
> >>> 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
> >> answered, the sender got the carrier tone, but the sender and receiver were unable to successfully negotiate a
> data rate.
> >>>
> >>>> 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
> >>> 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
> >>> 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'.
> >>>
> >>> 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...)
> >>>