Subject: IPP> PRO - Re: Print by reference

From: Harry Lewis <[email-masked]>
Date: Thu, 5 Jun 1997 16:32:36 -0400

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.

I disagree.

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 <<<

---

From: "Scott Lawrence" <[email-masked]>
Date: Thu, 05 Jun 1997 16:48:54 -0400

>>>>> "HL" == Harry Lewis <[email-masked]> writes:

HL> As chair, I would like to hear your reasoning as to why the IPP
HL> group denies the fact that submission should be your highest
HL> priority because there is a Printer MIB available for providing
HL> device capabilities and a job MIB for monitoring the job.

  Surely you are not suggesting that an IPP client implementation must
  include SNMP as well as HTTP?  If you thought you were getting
  resistance to layering IPP on HTTP...

HL> Does IPP feel that they have failed if they do not provide a
HL> complete, end-to-end, all-in-one protocol?

  For submission, including at least all negotiation required to
  ensure that the submission is acceptable - yes, certainly; anything
  less would be a failure.

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/