Mike-san and Daniel-san,
I'll be out of office for bossiness trip,
so Akiko Mochizuki of Fuji Xerox will continue this discussion next week.
Thanks,
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: Friday, June 28, 2013 12:00 PM
> To: 'Michael Sweet'
> Cc: fx OHTAKE SHIN; 'ipp at pwg.org'
> Subject: RE: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments
>> Mike,
>> Yea, rewording the definitions makes sense then.
>> Paraphrasing --
>> fax-modem-carrier-lost: Lost connection to the receiver during send. (Receiver detected loss of carrier and could
> not acknowledge reception of carrier).
>> fax-modem-training-failure: The sender and receiver were unable to successfully negotiate a data rate. (Receiver was
> unable to agree with the data rate suggested by the sender (or) Receiver unable to receive the facsimile per the suggested
> data rate)
>> Or something better ....
>> Daniel.
>>> -----Original Message-----
> From: Michael Sweet [mailto:msweet at apple.com]
> Sent: Thursday, June 27, 2013 6:22 PM
> 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
-------------- 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/20130628/4787e64d/attachment.bin>