Subject: [IPP] RE: IPP FaxOut and "resource constrained MFDs"?

From: "Zehler, Peter" <[email-masked]>
Date: Thu, 1 Nov 2012 11:21:17 +0000

Smith,

I don't think there is an assumption that the MFD must cache the entire fax job locally to handle retransmissions.  An MFD that cannot handle retransmissions would represent that in its capabilities.  The FaxOutJobProcessing element RetryInfo element is optional.  An MFD implementation unable to cache an entire fax job would not advertise that capability.  Standard MustHonor (i.e. ipp-attribute-fidelity in IPP) handles this limitation on job submission.  A fax job submission with MustHonor on RetryInfo would be rejected.  A job without MustHonor would omit RetryInfo or substitute '0' for the values of the constituent elements.

DestinationUris is a bit different.  Currently there is no way to determine before submitting a job if the MFD is capable of delivering a fax job to multiple destinations.  In the FaxOutJobProcessingCapabilities element DestinationUris we covered the supported URL schemes to enable support for various flavors of fax such as ITU and IETF.  Also covered is the support of fields from rfc2806 that were dropped in rfc3966 but are needed to route a fax  (e.g., preDialString, postDialString and T33Subaddress).  There is no element to indicate if multi-destination jobs are supported.  The element should be a peer of DestinationUris and not contained within. Pity you weren't around a year and a half ago so there would be one.  An MFD that handles only single destination jobs is supported during job submission through the standard MustHonor processing.

The PWG Semantic Model will allows such extensions.  Since an IPP protocol binding of fax and scan are being discussed I would think that the fax specification would be a good place to define the element and have it included in the semantic model schema.  

Peter Zehler,

Xerox Research Center Webster
Email: [email-masked]
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kennedy, Smith (Wireless Architect)
Sent: Wednesday, October 31, 2012 4:03 PM
To: [email-masked]
Subject: [IPP] IPP FaxOut and "resource constrained MFDs"?

Greetings,

In reading the IPP FaxOut specification, it seems that there is an assumption that the MFD must cache the entire fax job locally to handle retransmissions and to also support multiple destinations.  Obviously for those MFDs that have enough RAM or secondary storage, this is not a problem.  But what of those MFD type devices that may not have such resources?  It seems pretty clear to me that resource-constrained MFDs were not considered in the IPP FaxOut specification.  It seems clear to me that additional attributes and use discussion will be needed to the IPP FaxOut specification if this class of devices is to be supported.

Will the semantic model upon which IPP FaxOut is based allow for such extensions?  I will begin reading 5108.5 and 5108.1 more closely, but if those that were authors of those specifications or the draft of IPP FaxOut could comment on this, it would be appreciated.

Cheers,
Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
    [email-masked]
*/

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

-- 
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: Randy Turner <[email-masked]>
Date: Thu, 1 Nov 2012 04:57:12 -0700

Hi Pete,

I think Smith's assertion is correct - from my reading of your first paragraph below, if you support retransmissions, the assumption is you can cache the entire job.  Advertising the capability is a separate issue.  So the answer is "yes", the assumption is that the device can cache the entire job.  If a device can't do this, then the recommendation is not to advertise the capability.

At least that's how I interpreted the first paragraph of your email below…

Randy

---

From: Michael Sweet <[email-masked]>
Date: Thu, 01 Nov 2012 07:59:16 -0400

Smith,

Aside from Pete's excellent comments, I'll throw in my $0.02CDN as the editor for the document:

- IPP and the Semantic Model are all about extensions, and we have lots of them... :)

- I had actually thought that MFDs would be able to handle storing and retransmitting documents, mainly because I figured that fax-in and fax-out go hand-in-hand and most of the MFDs I've used have been able to store incoming documents to deal with "out of paper" issues.  But you raise an important point and I will add text explicitly covering that use case/type of printer.  On the print side we already support stream-only printers so it should be straight-forward to expose this for FaxOut.

- Regarding multiple destinations, I think it makes sense to add a "multiple-destination-uris-supported" Printer attribute so that a printer can advertise whether they support more than 1 destination URI.  I will add this to the next draft.

> Will the semantic model upon which IPP FaxOut is based allow for such extensions?  I will begin reading 5108.5 and 5108.1 more closely, but if those that were authors of those specifications or the…

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Randy Turner <[email-masked]>
Date: Thu, 1 Nov 2012 05:09:14 -0700

Historically, I think the assumption for fax machines is that CCITT error handling mechanisms REQUIRED that fax machines be able to cache a single "PAGE" of information.  In my experience, there is no such thing as a fax machine so resource constrained that it cannot cache a single page, so maybe we should think about this in our discussion of assumed caching requirements.  If you had a 50-page job, you received confirmation on a page-by-page basis, so there was no reason to cache an entire job.

R.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 01 Nov 2012 08:12:33 -0400

Randy,

Thanks, I will include this in the updated draft as well.

---

From: "Zehler, Peter" <[email-masked]>
Date: Thu, 1 Nov 2012 12:12:36 +0000

Randy,

The point of my first paragraph below is that an MFD is not REQUIRED to support caching the entire job.  This is true not only of Fax but also of print.  Fax might need to cache the job for retries and print might need to cache the job for multiple copies.   Of course fax and print could accomplish their tasks without caching the documents if the documents were submitted by reference (i.e. using a document URI). 

Peter Zehler

-----Original Message-----
From: Randy Turner [mailto:[email-masked]] 
Sent: Thursday, November 01, 2012 7:57 AM
To: Zehler, Peter
Cc: Kennedy, Smith (Wireless Architect); [email-masked]
Subject: Re: [IPP] RE: IPP FaxOut and "resource constrained MFDs"?

Hi Pete,

At least that's how I interpreted the first paragraph of your email below...

Randy

On Nov 1, 2012, at 4:21 AM, "Zehler, Peter" <[email-masked]> wrote:

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

---

From: Randy Turner <[email-masked]>
Date: Thu, 1 Nov 2012 05:28:10 -0700

Should we include (enumerate) some examples of how to accomplish advertised functionality WITHOUT device-local caching?

This would correct any false assumptions about job caching being required to accomplish certain advertised functionality.

print(fax out) by reference is a good example whereby my device can support complete job retries without local caching (as you say below)

R.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 01 Nov 2012 09:31:28 -0400

Randy,

> Should we include (enumerate) some examples of how to accomplish advertised functionality WITHOUT device-local caching?

I think it is important to address the stream vs. spool use cases, but I *don't* think we need to enumerate the implementation options for each type of printer.  As Pete pointed out, IPP already handles such things as copies and duplex where at least some content needs to either be cached by the printer or the job has to be aborted so that the client can resubmit when an exception occurs.  I don't see fax retransmission as any different, aside from some new job-state-reasons values to tell the client what happened.

> print(fax out) by reference is a good example whereby my device can support complete job retries without local caching (as you say below)

That isn't really true in the general case, since the printer needs to cache at least some of the remote content in order to render/print/fax it and not all remote stores allow random access to the data making retries potentially resource intensive.

I often see "print by reference" being heralded as the fix for all of our woes, but in reality little has changed since we introduced it some 15 years ago - it works for certain specific use cases but is no substitute for the client supplying the print data because a URI generally does not contain all of the information needed to reproduce what the client would supply to the printer (beyond credentials/cookies/etc., the software used to generate the printable content and any client-side processing intent).  Having the client be the server for the reference solves some of those issues but places an undue burden on the client implementations and introduces a lot of issues on mobile devices (fax, then walk away and the printer cannot access the document to be faxed) - better to just make sure direct, streamed printing/fax can be supported by both sides and let print/fax-by-reference be a bonus/optimization option that is available.

Also, for fax-out we can't assume that the printer can produce a cover sheet or that the client would want it to.  More than likely the client will want to supply the cover sheet for the fax, which means direct printing or print-by-reference with the client as the server.