Hello All,
This discussion is exposing several issues and questions. I suggest that
there should be some consideration of these in the SM meeting as well.
1. Since the PWG has an approved candidate standard that Nancy suggests
does not agree with the current schema, which takes precedence? I suggest
that any SM change must be reflected in an errata in the Common Model or
specific Service candidate standard, as appropriate.
2. Has the Get<service>ServiceElements operation requested elements
actually been changed? The Common Model indicates that "Some Services may
accept an additional argument in a Get<service>ServiceElements request to
further filter the response. The individual Service specifications identify
such arguments if any, their effect and whether support is mandatory." My
interpretation of this is that the Common Model allows the distinction
between the SM and IPP operations to be eliminated for a specific Service if
the Service Specification so mandates. I do not see this mandate in the
FaxOut Service Specification. Should it be there?
3. In regard to GetFaxOutServiceElements and GetFaxJobElements as well
as other operations (e.g., Activate and Deactivate), the proposed IPP FaxOut
binding appears to follow IPP Printing rather than the SM FaxOut
specification. (i.e., although the IPP binding may allow specifying groups,
it is mandated in the SM) Is this divergence valid? Or, if the differences
are necessary, should the SM FaxOut specification be updated? And if this
update violates the Common Model, should that be updated? Essentially,
should we be consistent among our standards?
4. Returning to the issue of desired capability, I may have gotten
lost, but it appears that three levels of Service capabilities are desired.
Is this correct?
a. Currently configured, provided by Get-Printer-Attributes and
(perhaps) by GetFaxOutServiceElements
b. Values that the implementation allows an administrator to configure,
provided by Get-Printer-Supported-Values ( I find RFC 3380, 4.3, para 4
totally confusing and suggest that clarification is in order)
c. The "original manufacturer xxx-supported values", which depending
upon ones interpretation, may not be provided by IPP. The term "default" in
the discussion is unclear. Is the interest in manufacturer default
configuration (why?) or the 'out-of-box' capabilities that an administrator
could configure?
5. So, whether or not IPP provides it in Get-Printer-Supported-Values
(which seems to depend upon the implementer's interpretation), it is desired
to include in the FaxOut SM a capability to get the full set of supported
values for read/write elements. Although some clarification is necessary, I
think that Get<service>ServiceElements/Capabilities may provide this, as
distinguished from Get<service>ServiceElements/Configuration which would
correlate with Get-Printer-Attributes.
6. Finally, in addition to the potentially new
Get<service>ServiceSupportedElements operation (or whatever to call it) to
be added to the FaxOut (and probably other Service SM) specifications, the
discussion suggested that the SM group add the following:
a. Handling of subscriptions
b. Identify<service>Service
From: Ying Chen [mailto:chen.nancy5 at gmail.com]
Sent: Thursday, March 07, 2013 5:09 PM
To: Michael Sweet
Cc: William A Wagner; ipp at pwg.org; mfd at pwg.org
Subject: Re: [IPP] Re: [MFD] Comments on IPP Faxout Spec w/r SM FaxOut
Service
Mike and Bill,
I'd like to point out two things:
1. In Bill's #4 regarding SM GetFaxOutServiceElements request, it stated
that "the allowed values for Requested Elements are Service Capabilities,
Service Configuration, Service Description, Service Status or DefaultJob
Ticket." These are what specified in the current MFD Common SM 2.0 spec.
However the MFD Schema has evolved since. The Requested Elements can be any
element in the service. But for operational efficiency, it is recommended
to get a larger group element.
I think the MFD Common Semantic Model should be updated accordingly.
2. In Mike's response to #5, regarding Get-Printer-Supported-Values -
>From rfc3380 page 1, "The Get-Printer-Supported-Values administrative
operation returns values that the IPP Printer will accept for setting its
"xxx-supported". Notice that this operation does not return any
"xxx-supported" values that cannot be set by an administrator. Hence Mike
is correct that "use Get-Printer-Supported-Values to get the full set of
values that can be configured", but I did not see any semantic in rfc3380
that defines "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" as Mike said.
In MFD SM, "xxx-supported" attributes are defined in the
"<service>ServiceCapabilities" group element, each elements in this group
most of times is either a list of keywords or a range of values between a
Lowerbound and Upperbound elements representing the allowed values for the
xxx-supported attribute, or a boolean representing whether an attributed is
supported or not. There is a xxx-supported value for every
<service>JobTicket element and every <service>JobDocument element. For
example, the JobHoldUntil element in JobTicketCapabilities is a list of
keywords: "DayTime" "Evening" "Indefinite" "Night" ...etc, the Priority
element has a Lowerbound and Upperbound sub-elements of integer type. All
Capabilities elements in MFD SM are settable by Admin.
Therefore, Mike is correct that there is no element in MFD SM that defines
"the original manufacturer xxx-supported values". I think this set of
values are very useful when there is a need to restore <service> attributes
to the manufacturer's defaults. But I don't see the IPP spec (rfc3380) has
this set of attributes defined either.
-Nancy
-------------------------------------------
Nancy Chen
Independent contributor, PWG Vice-Chair
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 <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
--
Nancy Chen
--
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/20130309/0f112723/attachment-0001.html>