I certainly agree with your (and Bob's) proposal.
...jay
----- Begin Included Message -----
From: Paul Moore <paulmo@microsoft.com>
To: "'JK Martin'" <jkm@underscore.com>
Cc: ipp@pwg.org
Subject: RE: IPP> Job identification mandatory
Date: Thu, 17 Jul 1997 11:30:15 -0700
No its not a transaction ID its a job ID. The point is that the current
model allows a server to refuse to supply a job identification attribute
- I am proposing that the server always return a job identification
attribute if so requested.
> -----Original Message-----
> From: JK Martin [SMTP:jkm@underscore.com]
> Sent: Thursday, July 17, 1997 8:06 AM
> To: Paul Moore
> Cc: ipp@pwg.org
> Subject: Re: IPP> Job identification mandatory
>
> Paul,
>
> Sorry, but I'm a bit confused by what you refer to as a
> "job identifier". Perhaps I'm incorrectly reading your
> text, but it sounds like "job identifier" is more of a
> "transaction identifier".
>
> The purpose of the GetJobs operation is to return one or
> more job identifiers from the target Printer (right?).
> Then exactly what are you and Bob proposing?
>
> So sorry if I'm being a bit dense here.
>
> ...jay
>
> ----- Begin Included Message -----
>
> From ipp-owner@pwg.org Wed Jul 16 20:35 EDT 1997
> From: Paul Moore <paulmo@microsoft.com>
> To: "'ipp@pwg.org'" <ipp@pwg.org>
> Subject: IPP> Job identification mandatory
> Date: Wed, 16 Jul 1997 17:25:27 -0700
>
> Change to model following review of protocol.
>
> BobH and I propose that getjobs must always return a unique job
> identification (either jobid or job URL , see other recent mail) that
> can be used in subsequent requests.
>
> The reason is that most print API work this way and so most clients
> are
> structured on this assumption. (Specifcally in the MS world the
> EnumJobs
> API always returns a job identifier).
>
>
>
> ----- End Included Message -----
----- End Included Message -----