I'm resending this lost message.
Tom
-----Original Message-----
From: Hastings, Tom N
Sent: Friday, July 14, 2000 16:52
To: 'kugler at us.ibm.com'
Cc: Michael Sweet; ipp at pwg.org
Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
Printer Admin (Set2) spec
Section 1 has:
The Internet is a distributed computing environment where requesters of
print services (clients, applications, printer drivers, etc.) cooperate and
interact with print service providers. This model and semantics document
describes a simple, abstract model for IPP even though the underlying
configurations may be complex "n-tier" client/server systems.
Further in section 1.1 after the Figure:
An IPP Printer object encapsulates the functions normally associated with
physical output devices along with the spooling, scheduling and multiple
device management functions often associated with a print server. Printer
objects are optionally registered as entries in a directory where end users
find and select them based on some sort of filtered and context based
searching mechanism (see section 16). The directory is used to store
relatively static information about the Printer, allowing end users to
search for and find Printers that match their search criteria, for example:
name, context, printer capabilities, etc. The more dynamic information,
such as state, currently loaded and ready media, number of jobs at the
Printer, errors, warnings, and so forth, is directly associated with the
Printer object itself rather than with the entry in the directory which only
represents the Printer object.
IPP clients implement the IPP protocol on the client side and give end users
(or programs running on behalf of end users) the ability to query Printer
objects and submit and manage print jobs. An IPP server is just that part
of the Printer object that implements the server-side protocol. The rest of
the Printer object implements (or gateways into) the application semantics
of the print service itself. The Printer objects may be embedded in an
output device or may be implemented on a host on the network that
communicates with an output device.
Section 2.1:
Some examples of configurations supporting a Printer object include:
1) An output device with no spooling capabilities
2) An output device with a built-in spooler
3) A print server supporting IPP with one or more associated output devices
3a) The associated output devices may or may not be capable of spooling jobs
3b) The associated output devices may or may not support IPP
Legend:
##### indicates a Printer object which is
either embedded in an output device or is
hosted in a server. The Printer object
might or might not be capable of queuing/spooling.
any indicates any network protocol or direct
connect, including IPP
embedded printer:
output device
+---------------+
O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
hosted printer:
+---------------+
O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | |
########### +---------------+
+---------------+
fan out: | |
+-->| output device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+-->| output device |
| |
+---------------+
We didn't want to introduce the Server as an object for the same reason that
we didn't want to introduce the output device as an object. It wasn't
necessary for our simple client-server protocol.
For the Redirect-Job, the "redirection-printers-supported" Printer Attribute
is all that is necessary for a Printer to indicate to which other Printers
it is willing to redirect output. We don't need to introduce a Server
object to help with the simple Redirect-Job that redirects jobs among
Printers on the same server.
Ok?
Tom
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Thursday, July 13, 2000 14:48
To: Hastings, Tom N
Cc: Michael Sweet; ipp at pwg.org
Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job
andPr inter A dmin (Set2) spec
The only definition of "server" that I can find in the Model is this:
> An IPP server is just that part of the Printer object that implements the
server-side protocol.
Putting that together with this statement from the Redirect-Job spec:
> This operation is limited to redirecting a job to another
> Printer on the same server.
yields a peculiar model. Looked at from an OO point of view, the first
statement implies that a Printer contains a server, in a one-to-one
relationship. However, the second statement implies that a server contains
one or more Printers. This seems confusing and somewhat
self-contradictory.
-Carl
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 07/12/2000 01:18:59 AM
To: Carl Kugler/Boulder/IBM at IBMUS, Michael Sweet <mike at easysw.com>
cc: ipp at pwg.org
Subject: RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job andPr
inter A dmin (Set2) spec
Carl wrote:
I could see this argument if the Redirect-Job target were a different
Device within a Printer. But since the target is a different Printer, and
server is undefined, this operation seems poorly specified to me.
The IPP Model explains server, and how it relates to the protocol and the
IPP Printer object. However, it doesn't introduce "server" as a formal
object, just as it doesn't introduce "output device" as a formal object.
However, from a client's point of view, it can discover to which Printer's
the Printer can Redirect jobs because the Printer supports the Redirect-Job
for the Printers specified in the Printer's
"redirection-printers-supported"
(1setOf uri).
Tom
-----Original Message-----
From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
Sent: Tuesday, July 11, 2000 08:51
To: Michael Sweet
Cc: ipp at pwg.org
Subject: Re: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job
andPrinter A dmin (Set2) spec
Michael wrote:
>>kugler at us.ibm.com wrote:
>> ...
>> > This operation is limited to redirecting a job to another
>> > Printer on the same server.
>>>> This limitation seems a bit restrictive, particularly since the
>> IPP Model doesn't even define a server object.
>>When we approached this topic before, we had a lot of discussion
>about how to implement this. IIRC the issues were:
>> 1. The job-id and job-uri might change, depending on the
> implementation.
I don't think that should be a problem, as long as the client requesting
the move is informed of the new ID and URI.
>> Several people stated that it had to change for
> accounting to work properly, although I personally don't
> agree with that opinion...
>> 2. Requiring the server to transfer jobs to another server
> was not acceptable to a lot of people.
>I don't know what a server is in IPP. We've got Printer, Job, and
Document. I wouldn't mind having a Server object though, along with a
Queue object. We (IBM) have considered implementing these as extensions.
> 3. What about job template options that don't map to the new
> printer object?
>If "ipp-attribute-fidelity" is true, then the job will be rejected by the
new printer. Otherwise, you'll get status 0x0001 and the new printer will
do what it can.
> 4. What if the old server doesn't support encryption, etc.
> required by the new server?
>Then the operation fails.
> 5. How do we pass authentication information to the new
> server?
>The same way it was received by the old Printer.
> 6. How do we handle errors (can't transfer job to remote
> server, etc.)
>The client is informed in the response to the Move-Job operation and/or by
notifications, polling, etc.
>I'm sure I'm missing something here.
>>The crux of the problem is that there is a definite need for a
>"move job" operation, but implementing it fully to handle
>transferring of jobs to remote servers can be tricky and may
>not be possible for embedded implementations (personally I wonder
>if that will be an issue - I don't see embedded implementations
>supporting many of these ops that are geared towards printing
>systems)
>I agree with you. It should always be an OPTIONAL operation.
>The proposed Redirect-Job operation sidesteps some of the harder
>issues and will allow us to partition the functionality a bit.
>That is, provide a "lightweight" redirect and a heavier Move-Job
>operation rather than a single heavy Move-Job op with several
>printer attributes describing what type of movement is supported.
>>In other words, Redirect-Job need only support local movement,
>while Move-Job needs to handle all cases (local and remote,
>authentication, encryption, etc.) with the corresponding
>overhead.
>I could see this argument if the Redirect-Job target were a different
Device within a Printer. But since the target is a different Printer, and
server is undefined, this operation seems poorly specified to me.
-Carl
>--
>______________________________________________________________________
>Michael Sweet, Easy Software Products mike at easysw.com>Printing Software for UNIX http://www.easysw.com