Smith,
Thank you for your comments, some responses inline below:
On Jun 26, 2013, at 1:39 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
> ...
> 4.1.2:
> - The notion of "spooling vs. streaming" seems to assume that a device is one or the other, regardless of the job size. I don't think this is necessarily the case. Some ...
> FaxOut service side? Or should such devices always present themselves as streaming devices to clients, and not try to spool small fax jobs?
Some media types, e.g., PWG Raster, are considered to be streaming formats, while others are basically always spooled formats, e.g., PDF and OpenXPS. JPEG is in that middle-ground - you can stream it but generally you "spool" in memory and decode in bands.
It might be useful to talk a bit about this, but a FaxOut printer can advertise its exact spool/stream capabilities by looking at any document-format attribute provided in a Get-Printer-Attributes request.
> - Exactly how does the IPP FaxOut Printer Object communicate to the IPP client that it is streaming vs. spooling? Should it be done using the maximum size of an incoming fax job, using one of the following?
> - job-k-octets-supported (RFC 2911)
> - *-k-octets-supported if it depends on the format?
These generally communicate the maximum size document that can be spooled. For a streaming format like PWG Raster, I would not expect the printer to have a maximum size limit beyond the physical limits of the printer that it advertises (resolution and media size).
The job-spooling-supported Printer attribute can be used to explicitly identify which modes a printer supports, with the returned values being filtered by the printer in the Get-Printer-Attributes response (see above). If if can retransmit an entire job, it is a spooling device. Otherwise it is a streaming device (for purposes of fax).
I think we could also make a statement in the FaxOut spec about PWG Raster being stream-only and JPEG/OpenXPS/PDF being spool-only.
> If not in this manner, which seems non-optimal because it is basically an implied interpolation, an explicit attribute seems necessary.
>> - Is the error handling described here adequate? Under what conditions would there need to be "larger portions of the job" retransmitted? Only in the event of a phone line connection failure? In that case, would the sending fax only send the pages unsent? Or would it be expected to resend the entire job? Are retries in the "processing" state?
Conceptually a printer might have accepted multiple pages and get a late error over the fax line. In most cases I wouldn't expect the printer to get more than 1 page buffered up at a time...
> 4.1.4:
> - Why must the job be retained for 300 seconds? A streaming device will only retain the last page.
It is just the job history (not the document data), and the 300 seconds comes from the Semantic Model FaxOut Service spec (section 7).
I will clarify that the Job *History* MUST be retained.
> - Feedback: "(section 7.4.21)" should be "(section 7.4.22)". This logging facility is confusing and seems incompletely described, here or in 7.4.22.
I can add a reference to the Common Log Format spec, now that it is approved. And of course fix the cross reference to the right section...
> 4.2:
> - Note 1: "MUST NOT" for Print-Job operation? That seems a bit extreme… Is this expected to be only true for the /ipp/faxout Printer Object but not for the /ipp/print Printer Object (if present)?
Correct. The point is to have a hard deprecation - the Semantic Model does not provide Print-Job or Print-URI, so the IPP/SM FaxOut service doesn't offer these operations either. (historically the existence of Print-Job/Print-URI was a compromise for some companies that didn't want to provide a job history for anything but the currently printing job...)
> 4.3:
> - What is the purpose of margins here? Is this just for rendering local to the IPP Faxout device? (Guessing the answer is yes…)
It is more for making the FaxOut service look as much like an IPP Everywhere printer as possible.
> - "pages-per-minute" and "pages-per-minute-color" - how will this be determined for fax?
We should define this; probably as a function of the fax modem technology being used.
(i.e. maximum bit rate / constant for page bit size = pages-per-minute)
> - Should there be an "include-fax-header" job attribute? (this is a page header with the sender's name & #, date, time, page X of Y, etc.) Legal requirements around this?
Yeah, legal requirements (I think) pretty much make this mandatory, and there is no control over it in the SM FaxOut spec.
> - "Note 4" seems to not have any attributes that reference it. Was this supposed to be referenced by the "input-source-supported" attribute?
Yes, good catch, but I am also missing:
input-attributes-default
input-attributes-supported
input-color-mode-supported
input-media-supported
input-orientation-requested-supported
input-quality-supported
input-resolution-supported
input-sides-supported
> 6.1:
> - Send-Hardcopy-Document operation and streaming devices and a resend - will the client be expected to resend if the job included a Send-Hardcopy-Document operation?
Yes, but then the client will need to provide instructions to the user (replace the document to be faxed and try again). But for hardcopy documents the printer should be able to control the buffering/scan rate to allow for retries of the current page. Also, pretty much every MFP I've used has scanned the entire document into memory before faxing...
A client resubmission would use Create-Job + Send-Hardcopy-Document...
> 7.2.2.3:
> - What document formats must be supported by the printer for the logo? Size limits? JPS3 had the printer-icons attribute defined in such a way that the icon must be in a particular format (PNG) and particular sizes.
We don't say, here or in SM FaxOut. Maybe we should add a logo-uri-formats-supported (1setOf mimeMediaType) Printer attribute? And require JPEG?
> - Guessing that the schemes supported could be determined by "reference-uri-schemes-supported" but that attribute is not listed in the IPP FaxOut spec at all
logo-uri-schemes-supported tells you what URIs can be used.
> 7.4.22:
> - How is this intended to work? Can this be a URI to a service on a host other than the one hosting the IPP FaxOut Printer Object? What should happen if the fax log hits a size limit? Is the size limit advertised?
It *can* point to an external host. We should probably include an example, including a syslog URI (probably the most common case). Oh, and I need to document it is READ-WRITE and MUST be listed in the printer-settable-attributes-supported attribute...
We should discuss the size limit issue on the mailing list (right now it is an imaginary durable log of infinite length, constructed from pixie dust...)
> 7.4.26:
> - Should this value be the country-defined value?
Yes, and I should add the "MUST reflect any local regulatory requirements" bit to the end.
> 7.4.27:
> - What is the point of retry-interval-supported for streaming devices? And which entity is responsible for keeping count for the retries? Is it the IPP FaxOut device, or the client?
Retry-interval still could control the interval between retries to retransmit the current page. The FaxOut device is responsible for keeping count of its own retries.
_________________________________________________________
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.