Subject: [IPP] Stable draft of IPP FaxOut posted

From: Michael Sweet <[email-masked]>
Date: Mon, 01 Apr 2013 22:34:19 -0400

All,

I have posted a stable draft of the IPP FaxOut specification to:

	ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130401.docx
	ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130401.pdf
	ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130401-rev.pdf

For WG Last Call...

_________________________________________________________
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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: <[email-masked]>
Date: Wed, 17 Apr 2013 17:24:37 +0900

Dear all, 

We have two questions regarding the stable draft of IPP FaxOut.

1. Send-Hardcopy-Document:
Since we cannot imagine the usage, we do not understand why this operation MUST be supported.
So could you tell us the use case of the Send-Hardcopy-Document operation?
If this operation is NOT critical for IPP FaxOut, we suggest to change it to be "optional" for implementing easily.

2. destination-statuses:
We want to clarify which transmission status value should be specified in the "destination-statuses" when a multiple destination job is canceled.
Details are described below, but we think it is slightly unclear.

"4.1.3 Job Terminating State
"The terminating state of an IPP FaxOut Job reflects the absolute final disposition of the Job. Jobs in the ‘canceled’ state were canceled by a User using the Cancel-Job, Cancel-Jobs, or Cancel-My-Jobs operations, regardless of whether any or all of the Job has been processed or partially transferred to its destination URI(s). The “destination-statuses” Job Description attribute (section 7.3.1) provides detailed information regarding the progress of the job prior to cancellation."

For example, the job has 5 destinations.
The job is canceled when the device is transfering fax document to 3rd destination.
 1. completed
 2. completed
 3. transfering <- The job is canceled in the middle of here  4. wait  5. wait

Are the "job-state" and the "destination-statuses" the following?
job-state: canceled
destination-statuses:
 1. completed
 2. completed
 3. processing
 4. pending
 5. pending

 OR

job-state: canceled
destination-statuses:
 1. completed
 2. completed
 3. canceled
 4. canceled
 5. canceled

Which is correct?

Regards,
Munehisa MATSUDA

--
Munehisa MATSUDA
BROTHER INDUSTRIES, LTD.
Software Development Dept. 1
TEL: +81-52-824-2345 Ext. 8880
mailto: [email-masked]
--

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Apr 2013 12:21:23 -0400

Hi,

> If this operation is NOT critical for IPP FaxOut, we suggest to change it to be "optional" for implementing easily.

If you have a scan head on your MFP then users will want to be able to fax documents from that scan head.  There are already a lot of mobile applications being provided that serve as alternatives to the printer's own control panel, so this operation would allow those applications to support faxout as well.

And FWIW, the current wording is based on the intended conformance of the Semantic Model FaxOut spec, which makes the operation required.

> Details are described below, but we think it is slightly unclear.

I'm happy to clarify the text here.

> ...

The latter.

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 17 Apr 2013 12:33:15 -0400

I seem to recall that we decided to make Send-Hardcopy-Document optional or
conditionally mandatory (if there is a scan capability) and were going to
ask for an errata on the SM FaxOut spec.

Bill W.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Wednesday, April 17, 2013 12:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut

Hi,

On 2013-04-17, at 4:24 AM, [email-masked] wrote:
> If this operation is NOT critical for IPP FaxOut, we suggest to change it
to be "optional" for implementing easily.

If you have a scan head on your MFP then users will want to be able to fax
documents from that scan head.  There are already a lot of mobile
applications being provided that serve as alternatives to the printer's own
control panel, so this operation would allow those applications to support
faxout as well.

And FWIW, the current wording is based on the intended conformance of the
Semantic Model FaxOut spec, which makes the operation required.

> 2. destination-statuses:
> We want to clarify which transmission status value should be specified in
the "destination-statuses" when a multiple destination job is canceled.

> "The terminating state of an IPP FaxOut Job reflects the absolute final
disposition of the Job. Jobs in the 'canceled' state were canceled by a User
using the Cancel-Job, Cancel-Jobs, or Cancel-My-Jobs operations, regardless
of whether any or all of the Job has been processed or partially transferred
to its destination URI(s). The "destination-statuses" Job Description
attribute (section 7.3.1) provides detailed information regarding the
progress of the job prior to cancellation."

The latter.

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

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Apr 2013 12:52:50 -0400

Bill,

> ask for an errata on the SM FaxOut spec.

Correct.  Apologies if I wasn't clear below, but Send-Hardcopy-Document is only required for printers with scanners.

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 17 Apr 2013 13:43:31 -0400

Mike,

Out of curiosity, it would seem possible (and perhaps it already exists) for
a cell phone to use its camera as a scanner and to implement Scan and/or
FaxOut services, perhaps even using an IPP binding.  Should we be
considering that?
Thanks,
Bill Wagner

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Wednesday, April 17, 2013 12:53 PM
To: William A Wagner
Cc: [email-masked]; [email-masked]
Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut

Bill,

On 2013-04-17, at 12:33 PM, William A Wagner <[email-masked]> wrote:
> I seem to recall that we decided to make Send-Hardcopy-Document 
> optional or conditionally mandatory (if there is a scan capability) 
> and were going to ask for an errata on the SM FaxOut spec.

Correct.  Apologies if I wasn't clear below, but Send-Hardcopy-Document is
only required for printers with scanners.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Michael Sweet
>> Since we cannot imagine the usage, we do not understand why this 
>> operation
> MUST be supported.
> If you have a scan head on your MFP then users will want to be able to 
> fax documents from that scan head.  There are already a lot of mobile 
> applications being provided that serve as alternatives to the 
> printer's own control panel, so this operation would allow those 
> applications to support faxout as well.
> 
> And FWIW, the current wording is based on the intended conformance of 
> the Semantic Model FaxOut spec, which makes the operation required.
> 
>> 2. destination-statuses:
> disposition of the Job. Jobs in the 'canceled' state were canceled by 
> a User using the Cancel-Job, Cancel-Jobs, or Cancel-My-Jobs 
> operations, regardless of whether any or all of the Job has been 
> processed or partially transferred to its destination URI(s). The 
> "destination-statuses" Job Description attribute (section 7.3.1) 
> provides detailed information regarding the progress of the job prior to
cancellation."
>> The job is canceled when the device is transfering fax document to 
>> 3rd
> destination.
>> ...
>> job-state: canceled
>> destination-statuses:
>> 1. completed
>> 2. completed
>> 3. canceled
>> 4. canceled
>> 5. canceled
>> 
>> Which is correct?
> 
> The latter.
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 17 Apr 2013 14:42:26 -0400

Bill,

> FaxOut services, perhaps even using an IPP binding.  Should we be

Not that it is a common use case, but there *are* existing mobile solutions that make a phone, when running an application, look like an IPP Printer.  Conceptually you *could* also make a phone look like a scanner or fax device.  But such solutions have some serious usability issues, such as not always being able to "print" from one application to the IPP Printer application on the same device due to memory/resource constraints.

If we *did* want to consider these "virtual printer" applications, I would focus on network accessibility and how to deal with an application/service that has been stopped due to temporary resource constraints.  This would have particular significance for cloud-based solutions, and point to some potential solutions ("wake up" notifications that cause the service to restart automatically...)

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 12:03:49 +0900

Hi Mike,

>The latter.

Thanks for clarifying.
But I thought that we have to provide each status just before the cancellation happens.
Because the text says "prior to". 

"The “destination-statuses” Job Description attribute (section 7.3.1) provides detailed information regarding the progress of the job prior to cancellation."

Regards,

O'Hara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Thursday, April 18, 2013 1:21 AM
To: Matsuda, Munehisa (BIL-SDEV1) 松田 宗久
Cc: [email-masked]
Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut

Hi,

The latter.

--
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, 18 Apr 2013 10:12:55 -0400

O'Hara,

> "The “destination-statuses” Job Description attribute (section 7.3.1) provides detailed information regarding the progress of the job prior to cancellation."

I suppose there is some room for interpretation here, and I will clarify in the next update of FaxOut.

The intent is to see whether sending of the job to a particular destination was completed, canceled, or aborted (i.e. what was the terminating state of the destination) to allow the client to resubmit the job at a later time as needed, but only using those destinations that did not already receive the job completely.

---

From: <[email-masked]>
Date: Fri, 19 Apr 2013 10:27:00 +0900

Mike,

>The intent is to see whether sending of the job to a particular destination was completed, canceled, or aborted (i.e. what was the terminating state of the destination) to allow the client to resubm…

Thanks
I think the above is reasonable to simplify the client side implementation,
If you update the specification, please pay attention to "aborted" as well.
Similar things are written there.

Regards,

O'Hara

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, April 18, 2013 11:13 PM
To: Ohara, Kiyotaka (BIL-SDEV1) 大原 清孝
Cc: Matsuda, Munehisa (BIL-SDEV1) 松田 宗久; [email-masked]
Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut

O'Hara,