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 at fujixerox.co.jp
---------------------------------------------------------------------
> -----Original Message-----
> From: Manchala, Daniel [mailto:Daniel.Manchala at xerox.com]
> Sent: Wednesday, July 10, 2013 3:57 AM
> To: Michael Sweet; fx OHTAKE SHIN
> Cc: 'ipp at 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 at apple.com]
> Sent: Tuesday, July 09, 2013 8:06 AM
> To: fx OHTAKE SHIN
> Cc: Manchala, Daniel; 'ipp at 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 at 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 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 at fujixerox.co.jp> > ---------------------------------------------------------------------
> >
> >
> >> -----Original Message-----
> >> From: Michael Sweet [mailto:msweet at apple.com]
> >> Sent: Friday, June 28, 2013 10:22 AM
> >> To: Manchala, Daniel
> >> Cc: fx OHTAKE SHIN; 'ipp at 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 at 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 at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of
> >>> Michael Sweet
> >>> Sent: Thursday, June 27, 2013 5:07 AM
> >>> To: fx OHTAKE SHIN
> >>> Cc: ipp at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4598 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130710/d265fb91/attachment.bin>