Subject: IPP> Job identification mandatory

From: Paul Moore <[email-masked]>
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).

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Jul 1997 11:06:25 -0400 (EDT)

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 [email-masked] Wed Jul 16 20:35 EDT 1997
From: Paul Moore <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: IPP> Job identification mandatory
Date: Wed, 16 Jul 1997 17:25:27 -0700

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

---

From: Roger K Debry <[email-masked]>
Date: Thu, 17 Jul 1997 12:52:55 -0400

Job URI is one of the attributes that Get-Attributes "can" return, are you just
asking that it "must" be returned?

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 07/17/97 10:46
AM ---------------------------

        ipp-owner @ pwg.org
        07/17/97 09:17 AM
Please respond to [email-masked] @ internet

To: paulmo @ microsoft.com @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP> Job identification mandatory

Paul,

 ...jay

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

---

From: Paul Moore <[email-masked]>
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:[email-masked]]
> Sent:	Thursday, July 17, 1997 8:06 AM
> To:	Paul Moore
> Cc:	[email-masked]

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Jul 1997 14:40:10 -0400 (EDT)

Ah, I see.  So Roger deBry was right, you're proposing that we mandate
that an IPP server always return a job ID if requested.

I certainly agree with your (and Bob's) proposal.

	...jay

----- Begin Included Message -----

>From [email-masked] Thu Jul 17 14:30 EDT 1997
From: Paul Moore <[email-masked]>
To: "'JK Martin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: IPP> Job identification mandatory
Date: Thu, 17 Jul 1997 11:30:15 -0700

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

---

From: [email-masked] (Robert Herriot)
Date: Thu, 17 Jul 1997 12:40:09 -0700

Here is some background for the proposal to make job-identification
an attribute that a Printer must return with Get-Jobs, if requested to
do so.

Originally, we said that a paranoid Printer might choose to return no
information about some jobs, but job-uri is special in that it uniquely
identifies the job.  So it seems reasonable that if a client asks for
it, the Printer should return it.  Paul and I discussed the possibility
that a paranoid Printer might return a special job-uri for secure jobs.
If a client used this job-uri in other operations, the Printer would
recognize it as a special uri that doesn't really reference the job.

This raises the issue as to whether such a special ("fake") job-uri is
also unique or can the same special job-uri be returned for all secure
jobs?

Bob Herriot

> From [email-masked] Thu Jul 17 11:57:40 1997
> Date: Thu, 17 Jul 1997 14:40:10 -0400 (EDT)
> From: JK Martin <[email-masked]>
> To: [email-masked]
> X-Sun-Charset: US-ASCII
> Sender: [email-masked]
> Content-Length: 2097
> X-Lines: 70
>