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 resubmit the job at a later time as needed, but only using those destinations that did not already receive the job completely.
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:msweet at apple.com]
Sent: Thursday, April 18, 2013 11:13 PM
To: Ohara, Kiyotaka (BIL-SDEV1) 大原 清孝
Cc: Matsuda, Munehisa (BIL-SDEV1) 松田 宗久; ipp at pwg.org
Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut
O'Hara,
On 2013-04-17, at 11:03 PM, kiyotaka.ohara at brother.co.jp wrote:
> 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."
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.
>> Regards,
>> O'Hara
>> -----Original Message-----
> From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Thursday, April 18, 2013 1:21 AM
> To: Matsuda, Munehisa (BIL-SDEV1) 松田 宗久
> Cc: ipp at pwg.org> Subject: Re: [IPP] Questions for the stable draft of IPP FaxOut
>> Hi,
>> On 2013-04-17, at 4:24 AM, munehisa.matsuda at brother.co.jp wrote:
>> 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.
>> 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.
>> Details are described below, but we think it is slightly unclear.
>> I'm happy to clarify the text here.
>>> "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.
>> ...
>> job-state: canceled
>> destination-statuses:
>> 1. completed
>> 2. completed
>> 3. canceled
>> 4. canceled
>> 5. canceled
>>>> Which is correct?
>> The latter.
>> _________________________________________________________
> 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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.