Subject: Re: IPP> Identifying jobs in requests

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 17 Jul 1997 07:20:21 -0700

At 05:11 PM 7/16/97 -0700, Paul Moore wrote:
>This is to propose a change to the model based on reviewing the
>protocol.
>
>At present the plan is that to cancel (for example) a job you send a
>cancel operation to the job's URL. 
>
>Bob Herroitt and I propose that this be changed: you send a cancel
>operation to the printer URL giving a JobId as a parameter.
>
>This has the advantage that the client only needs to know one URL for
>all operations on a given printer.
>
>This then carries through into GetJobs returning a set of Jobids instead
>of a set of Job URLs. A jobid is just an opaque token, the client should
>not attempt to use it except as a way of identifying a job back to the
>server.
>

Paul,

I am not too happy about this change.  Going back to our earlier discussions,
before you got involved, we determined to use URIs to identify Jobs because
it gave us the flexibility to actually create the Jobs under a different
server name (on the same or a different host), which might be useful in some 
bigger printing systems. Your solution seem to be optimized for the scenario
where you have a generic Web server in combination with a Printer in the same 
host. Your solution seems to just complicate things a bit in scrnarios where 
you have an embedded or dedicated HTTP server that only does printing.

In summary, I think your solution introduces new restrictions in our design,
which are not particularly desirable.  Is there any other way that you can
solve your design problem?

Carl-Uno

---

From: JK Martin <[email-masked]>
Date: Thu, 17 Jul 1997 16:44:33 -0400 (EDT)

> also using URLs to imply the job id means that we are tied to a specific
> transport - something we tried to avoid. If we were to use , say, raw IP
> then you would need to assign an IP port to each job or something like
> that.

Is this really true?  Do you mean we would be tying ourselves to HTTP
by using a URL as a job ID?

It would seem that just because we choose the use the syntax and
semantics of a URL doesn't mean we necessarily tie ourselves to HTTP,
right?

	...jay

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 17 Jul 1997 17:56:48 PDT

At 05:05 PM 7/17/97 PDT, Paul Moore wrote:
>Not the issue. I do not object to using URI as job identifiers - I
>object to not giving the job identifier in a job specifc request.
>
>To restate - when I do a canceljob operation I do not supply a job
>identifier - the target job is implicit in the transport endpoint - this
>ties us to a transport. 
>

Paul,

it seems that a lot of this discussion has been people talking past each
other, including myself.  I fully support your proposal as stated above.

On the more general issue that seems to have started up this whole thread
of discussion, namely whether a server should be able to suppress certain
attributes due to security restrictions, we seem to mix up general model
issues with security issues.  My take on that problem is the following:

1)  Either the Printer is open (non-secure), in which case the server
should return all the information.

2) Or the Printer is limiting access through some security restrictions,
usually requiring authentication and authorization. In this case, 

a) the client is either accepted and gets all the information, 
b) or it does not pass the security check and does not get anything.  

In consequence, I suggest that there is no half-way house cases where the
server would return some, but not all of the information and we should
amend the model document to reflect this.

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

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

Yes, it does appear that we have been in violent agreement all along,
that everyone now believes the target job URI must be specified at the
IPP protocol layer, regardless of the transport used.

It also sounds like we have consensus in support of the proposal
by Paul/Bob (that launched this interesting thread).

If we could only resolve all IPP issues this quickly!

	...jay

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

>From [email-masked] Thu Jul 17 21:12 EDT 1997
Date: Thu, 17 Jul 1997 18:11:41 -0700
From: [email-masked] (Robert Herriot)
To: [email-masked], [email-masked]
Subject: Re: IPP> Identifying jobs in requests
Cc: [email-masked], [email-masked]

I think that we are finally getting to the heart of this issue, namely
that the protocol currently puts the URI of the operation's target object
in the Request-Line of the HTTP operation, and it is not in the
application/ipp message body.

I think that I am hearing both Randy and Paul say that they think that
the target job or printer URI should be a parameter in the application/ipp
message body.  Am I right in my understanding?

Bob Herriot

> From [email-masked] Thu Jul 17 17:35:23 1997
> 
> Paul Moore wrote:
> 
> Ok, I think we're in violent agreement here....I agree that the
> operandsof an IPP operation should not be implied by any transport-level
> information;
> especially if we plan on moving IPP to other transports...
> 
> Randy
> 
> 
> >
> >
> > > -----Original Message-----
> > > From: Randy Turner [SMTP:[email-masked]]
> > > Sent: Thursday, July 17, 1997 5:05 PM
> > > To:   Paul Moore
> > > Cc:   'JK Martin'; [email-masked]
> > > Subject:      Re: IPP> Identifying jobs in requests
> > >
> > > Paul Moore wrote:
> > >
> > > > I mean that not using jobids at all (which is what we do at
> > present)
> > > > ties us to HTTP.
> > >
> > > In the model document, job identifiers are URLs. If we have pushed
> > > URLs
> > > out of themain body of the protocol up into the transport layer,
> > then
> > > this is a mistake. Job identifiers
> > > belong within the application/ipp body, and, according to the model
> > > document, object
> > > identifiers are in URL format. Also, the use of URL/URI strings as
> > > object identifiers in
> > > and of itself does not tie us to any one transport mechanism.
> > >
> > > Randy
> > >
> > >
> > > >
> > > >
> > > > In the current model a cancel job is done by posting a cancel
> > > > operation
> > > > to the job URL. No job id is sent, it is implied in the transport
> > > > endpoint.
> > > >
> > > > > -----Original Message-----
> > > > > From: JK Martin [SMTP:[email-masked]]
> > > > > Sent: Thursday, July 17, 1997 1:45 PM
> > > > > To:   Paul Moore
> > > > > Cc:   [email-masked]
> > > > > Subject:      RE: IPP> Identifying jobs in requests
> > > > >
> > > > > > also using URLs to imply the job id means that we are tied to
> > a
> > > > > specific
> > > > > > transport - something we tried to avoid. If we were to use ,
> > > say,
> > > > > raw IP
> > > > > > then you would need to assign an IP port to each job or
> > > something
> > > > > like
> > > > > > that.
> > > > >
> > > > >
> > > > > Is this really true?  Do you mean we would be tying ourselves to
> >
> > > > HTTP

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

---

From: [email-masked] (Robert Herriot)
Date: Fri, 18 Jul 1997 13:08:35 -0700

So, I think that we are in agreement that the model and protocol documents
should state that the operations whose target is a Printer shall include
a parameter called printer-uri and operations whose target is a job shall
include a parameter called job-uri.

Randy suggests that the value of job-uri/printer-uri could differ from
the request-uri on the HTTP Request-Line, but the model has no such
concept.  So unless there are strong arguments to the contrary, the
protocol document will state that the request-uri has the same value
as the printer-uri/job-uri in the operation.

Bob Herriot

> From [email-masked] Fri Jul 18 01:40:49 1997
> 
> Robert Herriot wrote:
> 
> Yes, this is basically the idea I was agreeing with.
> 
> >
> >
> > Bob Herriot
> >
> > > > identifier - the target job is implicit in the transport endpoint
> > -
> > > > this
> > > > ties us to a transport.
> > >
> > > > > > > semantics of a URL doesn't mean we necessarily tie ourselves
> > to
> > > > > > HTTP,
> > > > > > > right?
> > > > > > >
> > > > > > >       ...jay
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> 
> 
> 
>