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
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
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: Randy Turner [mailto:rturner at amalfisystems.com]
Sent: Thursday, November 01, 2012 7:57 AM
To: Zehler, Peter
Cc: Kennedy, Smith (Wireless Architect); ipp at pwg.org
Subject: Re: [IPP] RE: IPP FaxOut and "resource constrained MFDs"?
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
On Nov 1, 2012, at 4:21 AM, "Zehler, Peter" <Peter.Zehler at xerox.com> wrote:
> 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: Peter.Zehler at Xerox.com> 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: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of
> Kennedy, Smith (Wireless Architect)
> Sent: Wednesday, October 31, 2012 4:03 PM
> To: ipp at pwg.org> 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.
>smith.kennedy at hp.com> */
>>> --
> 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>> --
> 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>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.