Carl-Uno, my apologies, I did not intend my submission to be a COMPLETE summary
of all contributions (I left out many, like Roger deBry's comment that
Print-by-Reference should be a base capability in IPP, Jeff Copeland's
agreement thereto etc.). I was trying to characterize the status of the topic
in a concise manner and suggest a kernel around which consensus might result.
Since you reiterated your submission, however, it would be a disservice for me
not to take this opportunity to comment further.
>Print-by-reference is an optional feature like most other Printer features,
>and from a protocol point of view it is not very different from whether a
>printer can staple or not. It is true that that print-by-reference is more
>likely to be supported by print-servers rather than by small printers, but
>so what? When you ask the printer about its capabilities, it will tell you
>whether it supports print-by-reference or not. Like support for multiple
>documents in a job, you probably want to find out whether your printer
>supports it, before blindly submitting a job.
You use the word "optional" with some level of assurance, yet I believe
this is the crux of the debate. Also, the mechanism for determining
capabilities seems to be a bit more in question (query/submit vs.
submit/monitor) than your writings would imply.
>The limited functionality of SWP has little or nothing to do with the
>print-by-reference discussion. The major limitations with SWP lie in the
>fact that it does not support important functions such as Cancel job and
>Get attributes, which are much more important.
As I saw it, in SanDiego, the two most significant limitations of SWP were lack
of multi-documents per job and print-by-reference. SWP is mainly a submission
protocol. There is firm ground to argue that a standard submission protocol
should address these two items to some degree. It appeared to me that Paul was
actually willing (and even offered a suggestion) to discuss handling multi-doc
within the SWP framework, if we did not make it too difficult. (As I recall,
his suggestion was to use a "multi-doc" job attribute and a specific URL that
was expecting multiple docs per job).
As chair, I would like to hear your reasoning as to why the IPP group denies
the fact that submission should be your highest priority because there is a
Printer MIB available for providing device capabilities and a job MIB for
monitoring the job. Does IPP feel that they have failed if they do not provide
a complete, end-to-end,
all-in-one protocol? Are the Printer and Job MIBs useless in the IPP's eyes?
I agree that Cancel is a very important function. I never agreed with the JMP
that Cancel should be left out of the Job MIB. I would be glad
to see it addressed in either the monitoring or submission protocols.
>>> Harry <<<