Hi,
Pete and I have both argued that RestartJob (terrible) and
ReprocessJob (a subset of ResubmitJob) shouldn't be in the
Semantic Model v2.0 (except for legacy Print Service).
I don't want to put them in any IPP Multifunction services.
ResubmitJob is necessary and is accounting-friendly.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Thu, Mar 7, 2013 at 12:33 PM, Michael Sweet <msweet at apple.com> wrote:
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>> _______________________________________________
> mfd mailing list
>mfd at pwg.org>https://www.pwg.org/mailman/listinfo/mfd>>
--
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/0b4b8088/attachment-0001.html>