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.
On Nov 1, 2012, at 4:59 AM, Michael Sweet <msweet at apple.com> wrote:
> 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.
>>> On 2012-10-31, at 4:03 PM, "Kennedy, Smith (Wireless Architect)" <smith.kennedy at hp.com> wrote:
>> 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>> __________________________________________________
> 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>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.