Bill,
On 2013-03-09, at 5:47 PM, William A Wagner <wamwagner at comcast.net> wrote:
> 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.
>From a purely pragmatic perspective, I would say precedence for typographical/omission errors goes to whichever is right! :)
If we find genuine technical issues then we need to proceed carefully.
Regardless, we will need to do errata for the corresponding specs - at the very least to point to the current version of the schema that has the fix.
> 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?
Personally I am not so concerned about this aspect, although it would be nice for all services to support selection of elements as well as groups for efficiency, just like IPP already provides.
> 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?
IPP requires both groups and attributes (elements), and always has. There is some wiggle room for IPP implementations (a conforming implementation can just return everything with successful-ok-ignored-or-substituted-attributes, with requested-attributes in the unsupported attributes group), but functionally requested-attributes is just a performance optimization (with the exception of media-col-database)
> 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) byGetFaxOutServiceElements
> 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?
IPP provides A and B. We don't have a way to get C directly, but honestly I would expect B and C to be the same out-of-the-box most of the time.
> 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.
I don't think the question of Get-Printer-Supported-Values returning set B above is at issue - that is precisely what it is defined to return.
> 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.
See section 4.3 of MFD Model for the discussion of capabilities.
<service>ServiceCapabilities provides the currently configured/available job and document ticket elements and values. This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-supported attributes.
<service>ServiceCapabilitiesReady provides the ready job and document ticket elements and values. This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-ready attributes.
What we need is a new group, <service>ServiceCapabilitiesSupported, which provides the equivalent of IPP's Get-Printer-Supported-Values. This should also include a discussion of its use in conjunction with Set<service>ServiceElements.
....
FWIW, <service>ServiceDefaults provides the default job and document ticket elements and values. This is equivalent to what IPP's Get-Printer-Attributes provides in its xxx-default attributes.
<service>ServiceConfiguration provides a view of the components (essentially the Printer MIB properties) associated with the service. We have some very limited exposure of this in IPP attributes - printer-alert, printer-input-tray, printer-output-tray, and printer-supply.
_________________________________________________________
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/20130311/644b2f2c/attachment-0001.html>