[MFD] Comments on IPP Faxout Spec w/r SM FaxOut Service

[MFD] Comments on IPP Faxout Spec w/r SM FaxOut Service

Ira McDonald blueroofmusic at gmail.com
Thu Mar 7 17:55:52 UTC 2013


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/blueroofmusic
http://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/mfd/attachments/20130307/0b4b8088/attachment-0002.html>


More information about the mfd mailing list