Bill,
On 2013-03-16, at 1:08 PM, William A Wagner <wamwagner at comcast.net> wrote:
> ...
> 3. It is my , perhaps incorrect, understanding that the print job ticket elements in a job request did not need to specify values for all of the elements in the reported printer capabilities. Indeed, a job request could be sent without the client even querying printer capabilities. Therefore, although it may be desirable for a Client to support (which is to say, provide values for) a set of elements commensurate with the anticipated needs of the User, it is unnecessary to require clients to support some defined subset of elements or values. I therefore would moderate the contention that clients need to discover what elements are supported by the printer, to say that client would need to determine whether the printer support those elements and value that are of interest to the User. Therefore, element subsets may be at most useful suggestions to what different clients should support.
Correct. I think it would be a mistake to limit clients to particular subsets or to have them report what subset(s) they conform to. Not only is this error prone and make implementation more difficult, but honestly it doesn't fit with the model we have developed over the last 15+ years.
Generally speaking, we have only set client requirements where they are needed for interoperability or basic protocol support. And explicit in that strategy is the notion of a default job ticket (and document ticket, and subscription ticket) that provides the default values for any attributes/elements that are omitted by the client. If a client sends an attribute/element or value not supported by the printer, the printer can ignore it (returning the attribute/element in the list of ignored items) or return an error.
> 4. The Printer (and Cloud Print Manager) will support those few elements that are required and whatever additional elements are necessary to expose the service capabilities. There appears no reason that they should support elements for capabilities that do not exist. So the subsets are not applicable to them beyond perhaps being suggestions as to what features might be provided.
Agreed.
> 5. If these contentions are valid, the Cloud Server must communicate subset of printer capabilities determined by the printer and a subset of desired job elements determined by the Client. If Cloud servers have essentially infinite capacity, they should handle the full set of elements and values. But practically, if the Cloud Print Service is intended for an identifiable User base, it is probably justified to support both for capabilities and job requests, a subset of the full PJT elements and values. That is, a Cloud Print Service need support just an element subset which is the intersection of the client job requests and printer capabilities. I think that our proper subset was to be our suggestion of what might be in that intersection.
I actually thought that the original purpose of Glen's work was to define what a meaningful minimum set of elements would look like. We already have a somewhat large recommended set of elements in PJT. IPP Everywhere defines a somewhat smaller set. Glen's current document goes basically from the absolute minimum to the kitchen sink, with the three sets of elements not quite matching up with the PJT or IPP Everywhere minimums.
I think there is value in defining what is the minimum required to support basic printing (select a printer and print, without showing the user options). And it may be important to have a roadmap to show people new to the Semantic Model where to find an element for "option X" or "feature Y" so that we don't end up with a vendor re-inventing something we have already spent years defining. But I don't personally think we need to define different levels of conformance - if a printer implements a particular feature, then they should (must?) use the corresponding already-defined elements and values.
_________________________________________________________
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/mfd/attachments/20130317/9463387f/attachment-0002.html>