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

From: fx OHTAKE SHIN <[email-masked]>
Date: Thu, 27 Jun 2013 11:25:23 +0900

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.

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.

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

Thanks,
Shin
//
---------------------------------------------------------------------
Shin Ohtake     CTPF4D, Fuji Xerox Co.,Ltd.
                phone: +81-45-755-5474 (direct)
                mail:  [email-masked]
---------------------------------------------------------------------

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 27 Jun 2013 08:07:13 -0400

Shin,

Thanks for your comments!

Responses inline...

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

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

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

---

From: "Manchala, Daniel" <[email-masked]>
Date: Fri, 28 Jun 2013 00:26:04 +0000

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:

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,

Responses inline...

On 2013-06-26, at 10:25 PM, fx OHTAKE SHIN <[email-masked]> wrote:
> 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.

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

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

---

From: Michael Sweet <[email-masked]>
Date: Thu, 27 Jun 2013 21:22:06 -0400

Daniel,

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

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.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Fri, 28 Jun 2013 02:37:09 +0000

Section 6.1 Send-Hardcopy-Document Operation

This is a CONDITIONALLY REQUIRED Operation. The condition is that Printers with one or more scanning accessories MUST support this operation. At the same time, it requires that a client (SHOULD) check if the Printer supports the operation by querying the "operation-supported" Printer Description, and clients discover the available input sources by querying "input-source-supported" Printer Description. Is it the case that the *client* (MUST or SHOULD ?) specify that the job input comes from a hard copy via the scan input device? This requirement makes sense for small devices which are driven from a client driver on their PC but doesn't make sense for an enterprise or work group device which is shared by many users. Enterprise or work group devices have a local user interface which allow the user to program and submit jobs. 

Section 7.1 - These are all new attributes which go along with the new operation defined in section 6. As such they should be exempt (SHOULD as opposed to REQUIRED) if supplied by the user at client station.

Section 7.2.2 - This attribute is specified as being "CONDITIONALLY REQUIRED". Does the REQUIRED apply to each of the member attributes? There are a number of member attributes in this section which are not supposed to be overridden by the user or client (reference to section 6 about clients gives the impression that the user supplies the values that override values from system), and some which can be optionally supplied. 

*	7.2.2.1 date-time - this is not able to be overridden by the submitting user. The system defines the submission time.

*	7.2.2.2 from-name - this is filled in with the submitting user name (job-originating-user-name) for the job.

*	7.2.2.3 logo - This should be optional.

*	7.2.2.4 message - This should be optional.

*	7.2.2.5 organization-name - This should be optional.

*	7.2.2.6 subject

*	7.2.2.7 to-name - This should be optional.

Section 7.2.4 - 7.2.6 all three of these are CONDITIONALLY REQUIRED for spooling devices. The number-of-retries, retry-interval, and retry-time-out are all system level attributes that belong to the fax card and are not adjustable on a job per job basis. Are we suggesting that the settings for these attributes be exposed at a job level?

Section 7.3.1 The destination-status for each recipient is contained completely within the fax card and is only made available to the user through the confirmation sheet. The job level status reported to the UI's and job history only give the overall status of the entire job. This attribute should be changed to SHOULD. 

Sections 7.4.23 - 7.4.25 (printer-fax-modem-info, printer-fax-modem-name, printer-fax-modem-number)  Wish that these were SHOULD as opposed to REQUIRED as this will require the gathering of the information and make it available to IPP (also privacy issues ...) - but otherwise ok.

---

From: "Manchala, Daniel" <[email-masked]>
Date: Fri, 28 Jun 2013 03:00:12 +0000

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:[email-masked]] 
Sent: Thursday, June 27, 2013 6:22 PM
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,

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

---

From: fx OHTAKE SHIN <[email-masked]>
Date: Fri, 28 Jun 2013 15:23:44 +0900

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

> From: Manchala, Daniel [mailto:[email-masked]]
> Sent: Friday, June 28, 2013 12:00 PM
> To: 'Michael Sweet'
> Cc: fx OHTAKE SHIN; [email-masked]'
> Subject: RE: [IPP] Re: Fuji Xerox has reviewed the IPP FaxOut specification and has comments
> 
> Mike,
> 
> 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.
> 
> 
> > 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:
> 
> 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 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.
> >
> > 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.
> >
> > 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?
> >
> > 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.
> >
> >> 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
> support 'fax-modem-voice-detected'.
> >

---

From: Michael Sweet <[email-masked]>
Date: Fri, 28 Jun 2013 09:37:07 -0400

Daniel,

> This is a CONDITIONALLY REQUIRED Operation. The condition is that Printers with one or more scanning accessories MUST support this operation. At the same time, it requires that a client (SHOULD) ch…

The original SM FaxOut Service spec made this operation REQUIRED (unconditionally).

But even for office equipment, I think it makes sense to keep this conditionally required - consider someone at the MFD using their tablet of choice to send a fax. The application could be something created by the organization or something they've purchased as a solution, with the corresponding templates for a cover sheet, looking up of destinations from the user's address book, enforcement of corporate policy (e.g. anything faxed out has a copy sent to a corporate server for regulatory compliance), and so forth.

Doing that on the MFD is conceivably possible but is cumbersome, particularly if multiple vendors and generations of products are in use.

> Section 7.1 - These are all new attributes which go along with the new operation defined in section 6. As such they should be exempt (SHOULD as opposed to REQUIRED) if supplied by the user at clien…

See above.

> Section 7.2.2 - This attribute is specified as being "CONDITIONALLY REQUIRED". Does the REQUIRED apply to each of the member attributes? There are a number of member attributes in this section whic…

I can copy the minimum requirements from 7.4.3.

> *	7.2.2.1 date-time - this is not able to be overridden by the submitting user. The system defines the submission time.

This is part of the Semantic Model elements - if we shouldn't include this then I'll remove here and we should also remove it from the SM 2.0 elements as well.

> *	7.2.2.2 from-name - this is filled in with the submitting user name (job-originating-user-name) for the job.

This is the human-readable name supplied for the cover sheet.  Consider an admin faxing a document for their boss.  We could say something about the default from-name being the job-originating-user-name, though.

> *	7.2.2.3 logo - This should be optional.

It is.

> *	7.2.2.4 message - This should be optional.

It is.

> *	7.2.2.5 organization-name - This should be optional.

It is.

> *	7.2.2.7 to-name - This should be optional.

While there are cases where you blindly fax a document to a service center, there are also a lot of cases where you *do* know the recipient.  Definitely optional to supply by the Client, but I think we need the Printer to support it if they support cover sheets (now just "from-name", "to-name", and "subject").

> Section 7.2.4 - 7.2.6 all three of these are CONDITIONALLY REQUIRED for spooling devices. The number-of-retries, retry-interval, and retry-time-out are all system level attributes that belong to th…

They *are* exposed in the Semantic Model (otherwise I wouldn't have bothered). If the shouldn't be (fine by me) then I'll remove here and we need to remove from SM 2.0.

If they stay then I should probably add some verbiage about Printers enforcing local regulatory requirements and reference the appropriate sections for the Printer Description attributes.

> Section 7.3.1 The destination-status for each recipient is contained completely within the fax card and is only made available to the user through the confirmation sheet. The job level status repor…

I would tend to disagree since per-destination status is needed to support Client managed retries, and it *is* part of the Semantic Model (though optional for the abstract service specification).

While we *could* make this CONDITIONALLY REQUIRED for streaming devices, that seems inverted to me since a) spooling devices typically expose greater functionality and b) spooling devices may still stream for some document formats (e.g. PWG Raster). See the discussion on HP's comments for more info...

> Sections 7.4.23 - 7.4.25 (printer-fax-modem-info, printer-fax-modem-name, printer-fax-modem-number)  Wish that these were SHOULD as opposed to REQUIRED as this will require the gathering of the inf…

These come from the Semantic Model FaxOutServiceConfiguration group; the schema makes the FaxModems group optional here, but I think that is more a function of FaxOut also supporting non-modem fax delivery?  The SM FaxOut spec doesn't say anything about this...