Daniel,
On Jun 27, 2013, at 10:37 PM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:
> Section 6.1 Send-Hardcopy-Document Operation
>> This is a CONDITIONALLY REQUIRED Operation. The condition is that Printers with one or more scanning accessories MUST support this operation. At the same time, it requires that a client (SHOULD) check if the Printer supports the operation by querying the "operation-supported" Printer Description, and clients discover the available input sources by querying "input-source-supported" Printer Description. Is it the case that the *client* (MUST or SHOULD ?) specify that the job input comes from a hard copy via the scan input device? This requirement makes sense for small devices which are driven from a client driver on their PC but doesn't make sense for an enterprise or work group device which is shared by many users. Enterprise or work group devices have a local user interface which allow the user to program and submit jobs.
The original SM FaxOut Service spec made this operation REQUIRED (unconditionally).
But even for office equipment, I think it makes sense to keep this conditionally required - consider someone at the MFD using their tablet of choice to send a fax. The application could be something created by the organization or something they've purchased as a solution, with the corresponding templates for a cover sheet, looking up of destinations from the user's address book, enforcement of corporate policy (e.g. anything faxed out has a copy sent to a corporate server for regulatory compliance), and so forth.
Doing that on the MFD is conceivably possible but is cumbersome, particularly if multiple vendors and generations of products are in use.
> Section 7.1 - These are all new attributes which go along with the new operation defined in section 6. As such they should be exempt (SHOULD as opposed to REQUIRED) if supplied by the user at client station.
See above.
> Section 7.2.2 - This attribute is specified as being "CONDITIONALLY REQUIRED". Does the REQUIRED apply to each of the member attributes? There are a number of member attributes in this section which are not supposed to be overridden by the user or client (reference to section 6 about clients gives the impression that the user supplies the values that override values from system), and some which can be optionally supplied.
I can copy the minimum requirements from 7.4.3.
> * 7.2.2.1 date-time - this is not able to be overridden by the submitting user. The system defines the submission time.
This is part of the Semantic Model elements - if we shouldn't include this then I'll remove here and we should also remove it from the SM 2.0 elements as well.
> * 7.2.2.2 from-name - this is filled in with the submitting user name (job-originating-user-name) for the job.
This is the human-readable name supplied for the cover sheet. Consider an admin faxing a document for their boss. We could say something about the default from-name being the job-originating-user-name, though.
> * 7.2.2.3 logo - This should be optional.
It is.
> * 7.2.2.4 message - This should be optional.
It is.
> * 7.2.2.5 organization-name - This should be optional.
It is.
> * 7.2.2.6 subject
>> * 7.2.2.7 to-name - This should be optional.
While there are cases where you blindly fax a document to a service center, there are also a lot of cases where you *do* know the recipient. Definitely optional to supply by the Client, but I think we need the Printer to support it if they support cover sheets (now just "from-name", "to-name", and "subject").
> Section 7.2.4 - 7.2.6 all three of these are CONDITIONALLY REQUIRED for spooling devices. The number-of-retries, retry-interval, and retry-time-out are all system level attributes that belong to the fax card and are not adjustable on a job per job basis. Are we suggesting that the settings for these attributes be exposed at a job level?
They *are* exposed in the Semantic Model (otherwise I wouldn't have bothered). If the shouldn't be (fine by me) then I'll remove here and we need to remove from SM 2.0.
If they stay then I should probably add some verbiage about Printers enforcing local regulatory requirements and reference the appropriate sections for the Printer Description attributes.
> Section 7.3.1 The destination-status for each recipient is contained completely within the fax card and is only made available to the user through the confirmation sheet. The job level status reported to the UI's and job history only give the overall status of the entire job. This attribute should be changed to SHOULD.
I would tend to disagree since per-destination status is needed to support Client managed retries, and it *is* part of the Semantic Model (though optional for the abstract service specification).
While we *could* make this CONDITIONALLY REQUIRED for streaming devices, that seems inverted to me since a) spooling devices typically expose greater functionality and b) spooling devices may still stream for some document formats (e.g. PWG Raster). See the discussion on HP's comments for more info...
> Sections 7.4.23 - 7.4.25 (printer-fax-modem-info, printer-fax-modem-name, printer-fax-modem-number) Wish that these were SHOULD as opposed to REQUIRED as this will require the gathering of the information and make it available to IPP (also privacy issues ...) - but otherwise ok.
These come from the Semantic Model FaxOutServiceConfiguration group; the schema makes the FaxModems group optional here, but I think that is more a function of FaxOut also supporting non-modem fax delivery? The SM FaxOut spec doesn't say anything about this...
_________________________________________________________
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.