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 at underscore.com]
> Sent: Thursday, July 17, 1997 8:06 AM
> To: Paul Moore
> Cc: ipp at 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 at pwg.org Wed Jul 16 20:35 EDT 1997
> From: Paul Moore <paulmo at microsoft.com>
> To: "'ipp at pwg.org'" <ipp at 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 -----