Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted jobs

From: Tom Hastings <[email-masked]>
Date: Thu, 19 Jun 1997 16:55:30 PDT

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

---

From: JK Martin <[email-masked]>
Date: Fri, 20 Jun 1997 11:04:32 -0400 (EDT)

This is the kind of request that makes some people believe IPP is
"too fat", IMHO, and that IPP tends to represent "DPA Lite".

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 [email-masked] Thu Jun 19 20:04 EDT 1997
Date: Thu, 19 Jun 1997 16:55:30 PDT
To: [email-masked]
From: Tom Hastings <[email-masked]>
Subject: IPP> MOD - The Get-Jobs operation and completed/canceled/aborted
  jobs

Comments?

Tom and Bob

----- End Included Message -----

---

From: Tom Hastings <[email-masked]>
Date: Fri, 20 Jun 1997 11:09:56 PDT

>"too fat", IMHO, and that IPP tends to represent "DPA Lite".

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

---

From: JK Martin <[email-masked]>
Date: Fri, 20 Jun 1997 14:43:34 -0400 (EDT)

Tom,

> but a program can't process HTML.

I can see you've missed my point entirely.  (Sigh)

A strong contingent within the IPP group (namely, Microsoft, HP, Lexmark
and others) have long claimed that IPP should be maximally used with
browser-based techniques, and not native platform GUI applications.

In other words, those folks don't want to focus the use of IPP with
native GUI apps, but rather leverage HTML and web pages pointing to
Internet-capable "printers".

I don't really wish to dwell on this issue, Tom.  If you still don't
understand what I mean, then let's discuss it offline.

> get at the same information is not as harmful as you seem to suggest.

Harmful???  Again, you miss the point.  'Nuff said.

	...jay