------=_NextPart_000_0008_01BE7C2D.E075C660
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Carl-Uno,
Before I continue, I would like to say that I found the IPP documents
well-written and complete. I was also surprised at how robust the protocol
was. Even with my first buggy "Friday afternoon" attempt at a server I was
still able to print from the IPP clients that are around on the net.
Many high-end printers (including the high-end of the Xerox range) have a
separate RIP unit. They usually also have a cantankerous operator who steps
in and interferes with the natural order of things.
Incoming jobs are RIPped as soon as possible and then wait in the RIPped
state until they are printed. The job goes through states like this:
Pending --->Ripping---->Pending--->Printing--->Completed
If the printer catches up with the RIP it might start printing a job while
it is still being RIPped. The operator may also hold a job after it has
been ripped but before it is printed, perhaps to batch jobs requiring the
same print media.
This means that many jobs might be in the processing state, even if the
print unit itself has stopped, and that is in contradiction to the MOD 4.3.7
and 4.4.10 (and perhaps other sections).
There are two solutions.
Solution 1 is to assume that the Ripping --> Ripped --> Printing states are
all processing, and to have job-state-reasons for the sub-states. There is
already a job-interpreting and job-printing state reason, so we only need
job-interpreted as an extra state. If a job is held after it is Ripped, it
would go from processing/job-interpreted to held. When it is released, it
would go from held to processing/job-interpreted . It would then have to be
legal to hold a job that is in processing/job-interpreted.
Solution 2 is to let the job go back from processing to pending after it has
been ripped, but with the state reason job-interpreted. That makes it
easier to hold and release jobs that have been ripped, and might appear more
logical to a user, especially if the client does not distinguish between the
sub-states.
Either way, the client should expect to see more than one job in the
processing state, even if the printer has stopped. It is also possible to
have more than one job in each of the job-interpreting and job-printing
sub-states.
If a job produces a large amount of output, the operator might hold the job
after a while, in order to clear the backlog of higher priority jobs. In
this case the job has not been aborted, and the printer has not stopped, so
the job has passed from processing/job-printing to
pending-held/job-printing.
I lean towards solution 2, but the most important thing is remove the
restriction on having only one job in the processing state.
Regards,
Anthony Porter
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
Sent: Wednesday, 31 March, 1999 10:11 PM
To: anthony.porter@computer.org; 'Hastings, Tom N'; 'ipp'
Subject: RE: IPP> MOD - IPP/1.1 Issue Status - Issues Raised at Bake Off
2
Anthony,
Your issue is as valid as any discovered in the bake-off. It will be added
as issue #31.
Can you please come back with a detailed suggestion for which additional
job-state-reasons you think we need to resolve your problem?
Carl-Uno
> -----Original Message-----
> From: Anthony Porter [mailto:anthony.porter@computer.org]
> Sent: Tuesday, March 30, 1999 12:58 AM
> To: 'Hastings, Tom N'; 'ipp'
> Subject: RE: IPP> MOD - IPP/1.1 Issue Status - Issues Raised
> at Bake Off
> 2
>
>
> Tom,
> For issue 17 (Time attributes) You might consider having the
> printer return
> the number of seconds since the event occurred instead of the
> up-time at the
> event. This allows the client to display absolute time
> without the server
> needing a clock.
>
> I am disappointed that there has been no comment on my
> concerns regarding
> printers with a separate RIP processor. It is not possible to make a
> conformant IPP server for these machines until these issues
> are resolved.
>
> I think that this ought to be added to the issues list even
> though I was
> unable to attend the bake-off.
> Regards,
> Anthony Porter
>
>
> -----Original Message-----
> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf
> Of Hastings,
> Tom N
> Sent: Tuesday, 30 March, 1999 3:02 AM
> To: ipp
> Subject: IPP> MOD - IPP/1.1 Issue Status - Issues Raised at Bake Off 2
>
>
> I've copied this issue summary to:
> >> Text deleted
>
------=_NextPart_000_0008_01BE7C2D.E075C660
Content-Type: application/octet-stream;
name="Anthony Porter.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Anthony Porter.vcf"
BEGIN:VCARD
VERSION:2.1
N:Porter;Anthony
FN:Anthony Porter
ORG:Xeikon;R&D
TITLE:Project Consultant
TEL;WORK;VOICE:+32.3.44.31.614
TEL;WORK;VOICE:075-736639
TEL;HOME;VOICE:+32.2.762.84.91
TEL;CELL;VOICE:+32.75.73.66.39
TEL;WORK;FAX:+32.3.44.31.448
TEL;HOME;FAX:+32.2.770.21.43
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Xeikon=3D0D=3D0AR&D=3D0D=3D0AVrede=
baan 72;Mortsel;;B-2640;Belgium
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Xeikon=3D0D=3D0AR&D=3D0D=3D0AVrede=
baan 72=3D0D=3D0AMortsel, B-2640=3D0D=3D0ABelgium
ADR;HOME:;;Kerkedelle 30;Brussels;;B-1200;Belgium
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Kerkedelle 30=3D0D=3D0ABrussels, =
B-1200=3D0D=3D0ABelgium
URL:
URL:http://www.xeikon.be
EMAIL;PREF;INTERNET:anthony.porter@computer.org
REV:19990222T102415Z
END:VCARD
------=_NextPart_000_0008_01BE7C2D.E075C660--