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.orghttps://www.pwg.org/mailman/listinfo/ipp
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.