Jay,
We had agreed at the protocol meeting to remove a lot of fat from
Get-Jobs: we removed all filters (see pages 28-29 of IPP Model).
So the Job Owner and Job States input parameters are gone.
The requester now gets all jobs in all states.
This request was to put back the most important capability, namely
whether to return completed jobs or not.
Yes, a user can get back a list of jobs by getting an HTML page back,
but a program can't process HTML.
Perhaps you are suggesting that IPP never return completed/canceled/
aborted jobs, and that a program use the Job Monitoring MIB to get
back completed/canceled/aborted jobs?
By the way, having two protocols (IPP and SNMP Job Monitoring MIB) that
get at the same information is not as harmful as you seem to suggest.
It gives two views into the same implementation. As long as we make
sure there is harmonization of syntax and semantics between the two,
then we are giving the application writer the choice of which protocols
to use. For example, a driver that uses IPP to submit and cancel, should
also be able to use IPP to show the status, instead of being forced to
also implement SNMP and the Job Monitoring MIB.
Finally, we clarified that the protocol meeting that the IETF needs
a MIB for managing the IPP network protocol, e.g., the number of octets
passed, the number of octets returned, the number of job acceptances,
the number of job rejections, etc., but is not mandating a MIB for
the service, such as the Job Monitoring MIB.
Tom
>
>Microsoft and others repeatedly stated that GUI application
>issues such as viewing job status should be handled via standard
>web page interfaces, where the designer of the web page decides
>what information and options to provide the user.
>
>Also, after reading your message, I now know why Harry Lewis is
>so upset about the apparent disregard for the Job MIB and Printer
>MIBs in the overall IPP universe.
>
>If a GUI application wants a multi-programmatic way to acquire a
>list of jobs, why not just use the Job MIB? If instead you want
>a job listing "over the Internet", why don't you just point your
>browser to the appropriate URL and click away?
>
> ...jay
>
>----- Begin Included Message -----
>
>>From ipp-owner@pwg.org Thu Jun 19 20:04 EDT 1997
>Date: Thu, 19 Jun 1997 16:55:30 PDT
>To: ipp@pwg.org
>From: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted
> jobs
>
>Bob Herriot and I were talking about the agreement at the 6/17 PRO meeting
>to remove the filter from the Get-Jobs operation. We think that the order
>that jobs are returned should be specified as something like:
>
> The order of jobs in the Get-Jobs Response SHALL be the oldest to
> newest with respect to completion time (either actual or expected),
> irrespective of job state.
>
>The problem that remains, is that this means that the 'completed' jobs
>come back first, which are usually the least interesting, though valuable
>to obtain in some cases. A good GUI interface should scroll off most of
>the completed jobs and show a few of the recently completed jobs followed
>by the processing and pending jobs. However, that is a fair amount of
>work.
>
>If we leave the specification as always returning all jobs, some
>providers will discover that clients aren't doing anything user-friendly
>with the results when the provider keeps a lot of completed jobs around
>for status or tracking. Then these providers will abandon keeping completed
>jobs around, so that they don't look bad to users using clients that
>don't do good things with the completed jobs that come back first.
>
>So we propose to add a "return-completed-jobs" input parameter to Get-Jobs with
>the following values:
>
> 'first' - return 'completed', 'canceled', and 'aborted' jobs in order
> of actual completion followed by 'pending', 'pending-held',
> 'processing', and 'processing-stopped' jobs in order of expected
> completion.
> 'last' - return 'pending', 'pending-held', 'processing', and
> 'processing-stopped' jobs in order of expected completion
> followed by 'completed', 'canceled', and 'aborted' jobs in order
> of actual completion.
> 'never' - do not return 'completed', 'canceled', and 'aborted' jobs at all.
>
>The default value for this input-parameter SHALL be 'never'.
>
>Comments?
>
>Tom and Bob
>
>
>
>----- End Included Message -----
>
>
>