I'm convinced to with draw the suggestion about requiring the client to do
any Document operations.
Thanks for the discussion.
From: Dennis Carney [mailto:firstname.lastname@example.org]
Sent: Tuesday, October 29, 2002 05:14
To: Hastings, Tom N
Cc: email@example.com; Paul Moore; firstname.lastname@example.org
Subject: RE: IPP> Re: SM> Re: ISSUE 18: Or should the client be REQUIRED
t o support some of the Document operations?
I would think both my argument and Paul's would also argue against
conditionally mandating Cancel-Document. Additionally, this might have the
effect of pushing clients toward Send-Document instead of Create-Document,
since they can do that without then being forced to also support
Cancel-Document--not the effect you're trying to have, I don't think.
"Hastings, Tom N"
.xerox.com> cc: "Hastings, Tom N"
<email@example.com>, firstname.lastname@example.org, email@example.com
Subject: RE: IPP> Re: SM>
Re: ISSUE 18: Or should the client be REQUIRED t o support some of
10/28/02 06:53 PM the Document operations?
I hear what you are saying and see the problems of my proposal.
There was one comment on the SM telecon though that if the client creates
Document objects with Create-Document, then the client ought to be able to
Cancel such a Document. Now that we agreed to REQUIRE a Printer that
supports the Document object to also support Cancel-Document (like
how about REQUIRING a client to be able to cancel a document, if the client
supports the Create-Document operation? In other words, if a user makes a
mistake, then the client ought to allow the user to correct it without
having to Cancel the entire job.
So the client conformance statement would be:
A client MUST support the Cancel-Document operation, if it supports the
From: Paul Moore [mailto:firstname.lastname@example.org]
Sent: Monday, October 28, 2002 09:19
To: Dennis Carney
Cc: Hastings, Tom N; email@example.com; firstname.lastname@example.org
Subject: Re: IPP> Re: SM> Re: ISSUE 18: Or should the client be REQUIRED
to support some of the Document operations?
and requiring clients to support something is a strange thing to do. As
long as the client does what the user wants it to do why force ti to do
It servers that must be forced to do things so that client can be sure that
certian things will be available
"Dennis Carney" <email@example.com>@pwg.org on 10/28/2002 08:51:58 AM
Sent by: firstname.lastname@example.org
Subject: IPP> Re: SM> Re: ISSUE 18: Or should the client be REQUIRED to
support some of the Document operations?
I don't understand how we went from base IPP being written with an emphasis
on printing (not monitoring) to having IPP extensions forcing every client
to not only monitor, but to monitor using multiple different operations
(Get-Documents could be sufficient, couldn't it?). I'm not at all sure
that all clients in the world can be grouped into the three groups you
list, but the "Job submitting clients" you mention might be instructed to
submit Document Template attributes, but not do any monitoring at all.
I am a big fan of job monitoring clients, but I can't see MUSTing everyone
to agree with me. (Did I just coin a new verb? Drats--MUSTed again! :-)
"Hastings, Tom N"
.xerox.com> cc: email@example.com
Sent by: Subject: SM> Re: ISSUE 18:
Or should the client be REQUIRED to support some of the Document
10/28/02 09:00 AM
We agreed not to require the client to support any Document operations,
because of the various kinds of clients: Job submitting ones, Operator
clients that control the system, and Monitoring clients that monitor the
system. Also a Job submitting client might monitor the system using, say,
the PWG Job Monitoring MIB, instead of the Get-Document-Attributes and
How about a conditional client conformance statement like the following:
A client MAY support any of the Document object operations defined in
section 3. However, if the client supports supplying Document Template
attributes in Document Creation operations, then the client MUST support
of the following Document operations: Create-Document, Send-Data,
Send-Document, Get-Document-Attributes, Get-Documents, and Cancel-Document.
This archive was generated by hypermail 2b29 : Wed Oct 30 2002 - 04:22:51 EST