Bill,
Sorry, finally getting a chance to read through this and respond...
On Feb 24, 2013, at 4:50 PM, William A Wagner <wamwagner at comcast.net> wrote:
> In pursuing the question about the SM correlation to Get-Printer-Suppported-Values in table 1, Operations for IPP FaxOut, there appear to be several inconsistencies.
> 1. ValidateFaxOutJob does not exist. ValidateFaxOutJobTicket is probably intended.
Correct.
> 2. I find no RestartFaxOutJob in either the SM FaxOut Service or general SM Model. Does the make sense? There is a ResubmitFaxOutJob.
I believe IPP's Restart-Job was never brought into the Semantic Model because of the accounting issues is causes. I can ban its use in FaxOut, much like we've banned Print-Job and Print-URI, if people prefer...
> 3. The SM FaxOut Service does not appear to differentiate GetFaxOutJobElements from the general Get<service>JobElements, which has an important difference from IPP Get-Job-Attributes. Unlike the IPP Get-Job-Attributes, the GetFaxOutJobElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for RequestedElements are Job Receipt, Job Status, or Job Ticket. It is not clearly stated whether the FaxOut follows the Common Semantics (presumably it must) or the IPP printer approach.
I believe this is an artifact of the web services binding; IPP has attribute groups that can be requested (job-template, job-description, etc.) as well as individual named attributes, so I don't think this is an issue.
> 4. The SM FaxOut Service does not appear to differentiate GetFaxOutServiceElements from the general Get<service>ServiceElements, which has an important difference from IPP Get-Printer-Attributes. Unlike the IPP Get-Printer-Attributes, the GetFaxOutServiceElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for Requested Elements are Service Capabilities, Service Configuration, Service Description, Service Status or DefaultJob Ticket. This distinction is not clearly stated.
Same comment as for #3.
> 5. As follows from item 4, the correlation to SM Get-Printer-Supported-Values is GetFaxOutServiceElements with values of Service Configuration, Service Description and Service Status (??)
No, there is a semantic difference. Get-Printer-Supported-Values returns the original manufacturer xxx-supported values while Get-Printer-Attributes returns the values as configured by the administrator of the printer - a configuration utility would use Get-Printer-Supported-Values to get the full set of values that can be configured and Get-Printer-Attributes to get the currently configured values.
What we'd need is (effectively) a <service>DefaultConfiguration group in the Semantic Model to provide the same information.
> 6. Comment: - should the SM address subscriptions?
I think we need to for Cloud, at least.
> 7. ReleaseHeldNewFaxOutJobs does not exist. ReleaseHeldFaxOutJobs ( no 'new') is probably intended.
Correct.
> 8. Deactivate and Activate were dropped from the SM model. Do we really need these?
They are part of IPP already.
> 9. It might be noted that Startup-Printer correlates to StartupService (FaxOut) of the System Control Service.
Done.
> 10. Neither the SM FaxOut nor Common Semantics include an operation correlating to Reprocess-Job. It is not clear how this would act for FaxOut.
Same as for print I'd think - creates a new job as a copy of an existing one. But ResubmitJob works that way and also accepts a new job ticket, avoiding the race condition for supplying new values before the job starts processing.
Perhaps we should deprecate Reprocess-Job for IPP FaxOut and just have Resubmit-Job?
> 11. Schedule-Job-After correlates to PromoteFaxOutJob. If the predecessor Job is specified, PromoteFaxOutJob acts the same way as the IPP Schedule-Job-After operation.
Done.
> 12. There is no CancelFaxOutDocument in the FaxOut Service just a CancelFaxOutDocuments (note the 's') although the general semantics operations is Cancel<service>Document . Is this an error in the FaxOut Service spec?
Probably.
> 13. I find no IdentifyFaxOutService under FaxOut, Common Semantics or System Control Service. Should this be added to the SM FaxOut Service (and all other services) or perhaps to System Control Service?
It should be part of Common Semantics, with each service getting its own Identify<service>Service operation.
> 14. The FaxOut Service identifies the following operations that do not appear in the IPP FaxOut spec:
> a. ResubmitFaxOutJob
> b. ValidateFaxOutDocumentTicket
Yes, for some reason I missed adding those two operations to the table. Now added (for the next draft...)
....
I'll hold off on publishing a new draft until we've had a chance to review the current one, but perhaps we can discuss whether Restart-Job and Reprocess-Job belong in IPP FaxOut, then the next draft will be that much cleaner...
Thanks!
_________________________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130307/aeb250ec/attachment-0001.html>