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

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

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

Michael Sweet msweet at apple.com
Thu Jun 27 12:07:13 UTC 2013


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.




More information about the ipp mailing list