IPP> Job identification mandatory

IPP> Job identification mandatory

IPP> Job identification mandatory

Paul Moore paulmo at microsoft.com
Thu Jul 17 14:30:15 EDT 1997


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 -----



More information about the Ipp mailing list