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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
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
<Daniel.Manchala at xerox.com>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.
> ________________________________________
> 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
>>> --
> 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>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130709/d5c25bd4/attachment-0001.html>