Subject: Re: IPP> Identifying jobs in requests

From: "Carl Kugler" <[email-masked]>
Date: 2 Jun 1998 23:26:47 -0000

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

I think this is actually a bit of a jump from the original proposal in 

> > From [email-masked] Thu Jul 17 17:35:23 1997
> > 
> > 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.
> > 
> > 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
> > > > > > 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
> > > >
> > > >
> > 
> > 
> > 
> > 
> 
> 
> ----- End Included Message -----
> 
> 
>

---

From: "Carl Kugler" <[email-masked]>
Date: 2 Jun 1998 23:50:00 -0000

I agreee with Scott in "URLs within IPP operations", 
    http://www.findmail.com/list/ipp/3695.html
that it as a bad idea to embed "printer-uri" in the ipp message body.  I went back through the archives to see why "printer-uri" was added to IPP in the first place.

I think this is actually a bit of a jump from the original proposal in
"Identifying jobs in requests", 
    http://www.findmail.com/list/ipp/1700.html
which only asked for an embedded Job identifier, not an embedded Printer identifier, with the rationale that in some implementations a Job is not directly addressable and must be accessed through its containing Printer.

If we accept that Printers are always directly addressable, then there's no reason to put the target printer-uri in the application/ipp message body.  

    -Carl

---

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 08 Jun 1998 11:38:31 -0600

Carl has it right:

He is correct when he says:

> No, the "special position" is "outside of  the operation layer as the request-URI on the Request-Line at
> the HTTP level."  Currently, PRO says the target SHALL also be an operation attribute.  

> In my proposal, the target SHALL NOT appear as an operation attribute.  It is only specified as the 
> HTTP request-URI.

---

From: Paul Moore <[email-masked]>
Date: Mon, 8 Jun 1998 11:42:04 -0700

I obviously missed this one. So 'special position' means that literally. I
thought it mean 'special purpose'. 

For my interest. Why are we putting things in special positions?

> From:	Robert Herriot [SMTP:[email-masked]]
> Sent:	Friday, June 05, 1998 8:46 PM
> To:	Paul Moore; 'Carl Kugler'; [email-masked]
> Subject:	RE: RE: IPP> Identifying jobs in requests
> 
> We agreed recently that the following operation attributes would be
> ordered.
>     attributes-charset (always first for requests and responses)
>     attributes-natural-language (always second for requests and response)
>     printer-uri or job-uri (always third for requests, though we are
> discusses whether it should be present)
>     job-id (always fourth for requests if present )
> 
> At 05:00 PM 6/5/98 , Paul Moore wrote:
> >       I think we are approaching group consensus on this.  I propose
> that
> >we remove "printer-uri" and "job-uri" as request Operation attributes,
> but
> >leave them in their special position in the protocol.  
> >
> >       [Paul Moore]  What 'special position'? 
> > 
>

---

From: Paul Moore <[email-masked]>
Date: Tue, 9 Jun 1998 17:17:39 -0700

Currently, "printer-uri" is a MANDATORY Operation Attribute of the
Create-Job operation (see section 15.3.4.3 Validate the presence of a single
occurrence of required Operation attributes).

	[Paul Moore]  My reading of this was that it was a 'virtual'
attribute. You were not expected to encode it in the IPP packet. This is the
same way that the creatjob request does not encode the user name (it can
choose to do) rather the user is inferred from the transport.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 9 Jun 1998 17:59:23 PDT

>choose to do) rather the user is inferred from the transport.

I think that originally "printer-uri" was going to be a "virtual" attribute,
as you thought.  But later (last Fall?) we changed the Model and Protocol 
document so that the "printer-uri" attribute was required to be supplied 
by the client and include in the operation attribute group in the IPP packet
(which is defined by the application/ipp MIME type).  The thinking
was that we wanted the IPP packet and MIME type to be independent
of the transport.  So that we could send IPP over any transport, such
as SMTP or FTP, for examples.

(BTW, the Protocol examples forgot to make the change to include
the "printer-uri", so maybe that is part of the reason you think that
"printer-uri" is not needed in the Operation Attributes group in 
the IPP packet.)

See Section 3.1.3 Operation Targets in the Model:

  The operation target is a MANDATORY operation attribute that MUST
  by included in every operation request.

(The updated Model in 3.1.4 Operation Targets goes further so require
that the Operation Targets come right after the char-set and natural-language
in the Operation attributes group).

See also Section 15.3.4.3, which does not have an "*" next to
"printer-uri" meaning that the client MUST supply it in the operation
request.

So if we change our minds back to not putting the "printer-uri" target
in the IPP layer packet, we need to change the Model and the Protocol
documents.

Tom

---

From: Paul Moore <[email-masked]>
Date: Tue, 9 Jun 1998 18:13:55 -0700

I think that originally "printer-uri" was going to be a "virtual"
attribute,
	as you thought.  But later (last Fall?) we changed the Model and
Protocol 
	document so that the "printer-uri" attribute was required to be
supplied 
	by the client and include in the operation attribute group in the
IPP packet
	(which is defined by the application/ipp MIME type).  The thinking
	was that we wanted the IPP packet and MIME type to be independent
	of the transport.  So that we could send IPP over any transport,
such
	as SMTP or FTP, for examples.

OK. So we are saying that the URIs IN the protocol are NOT to be used as
transport adresses. They are in effect opaque cookies that the client must
do nothing with except send them back to the printer. They are really
job-name and printer-name. Either that or we explicitly state that these
fields only make sense in an HTTP-enabled environment (they cannot therefore
be mandatory for a universal protocol).

---

From: Josh Cohen <[email-masked]>
Date: Tue, 9 Jun 1998 20:42:12 -0700

> From: Randy Turner [mailto:[email-masked]]
> Sent: Tuesday, June 09, 1998 8:13 PM
> To: Paul Moore; 'Tom Hastings'
> Cc: 'Carl Kugler'; [email-masked]
> Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests
> 
> For reference purposes, can someone restate the problem (actually the
> scenario) with proxies that we are trying to address. I think some
> solutions that have recently hit the list are bordering on 
> "throwing the
> baby out with the bath water". Any concrete scenario examples 
> would be much
> appreciated, as I am still on the learning curve with HTTP 
> proxy behavior.
> 

When a proxy is deployed as part of a gateway, firewall or other
security system, one of its responsibilities is to filter and allow
or reject certain transactions across a network or organizational boundary
in either direction.
The issue is that the proxy should be able to understand enough information
to decide wether to allow or reject that request's passage.  When given
an IPP URL such as http://server/printer/queue, it has no way of
differentiating
this from a typical web browser's form submission.   Since form submission
and print job submission and or printer control are different in terms
of the anticipated functionality that the firewall admin allowed
(by allowing POST http requests ), the admin should be able
to allow one and not the other.
The real world case is a firewall/proxy administrator who
sets a policy which allows POST because his intent is to allow
"simple web access", which form submission is a part of.  Lets
say in this case that he is willing to allow simple web access,
but he is not interested in allowing IPP functionality, ie
print job submission and printer control.   

At the time IPP went to last call, the specification was to use
POST with an http URL.  This did not meet the goal of allowing
a proxy server administrator to recognize the request as an IPP
request instead of a form submission.

Keith has come back with the request to somehow make IPP requests
identifiable as different from simple http POST form submissions.

Numerous suggestions have been made, as referenced by carl-uno's
recent posts of the table.

---

From: Paul Moore <[email-masked]>
Date: Wed, 10 Jun 1998 09:06:41 -0700

> No, the URI is actually a URL that is to be interpreted according to
> "standard" rules for interpreting URLs (not sure if there is a "formal"
> standard for this). These resource identifiers are not opaque to clients.
> This does not mean that we are NOT transport independent, it only means we
> are identifying resources that must be accessed via the transport (scheme)
> that is specified in the URL. 
	[Paul Moore]  not so - for at least 2 reasons.

	1. In some transports the server cannot know the adressing scheme of
the client and so cannot form an adress that makes sense for the client. A
URI is meant to be Universal (hence the name) - even if a server can form a
URI that makes sense in the addressing scheme of the original client, what
happens if this is forwarded to another client? Example - in a 1284
connected environment what should the URI look like (ipp:/lpt1/jobx ?), how
does the server know which lpt port number to use.

	2. I cannot forward an IPP packet containing a URI to another system
that is not part of the same homogeneous address space as the original
client and server. I have to crack every packet , find all the URIs and
change them. However I do not know HOW to change them because we have
avoided making rules about the formation of URI (they are supposed to be
implementation specific), without the knowledge of which bits mean what in
the URI I cannot know how to change them from one transport to another

---

From: Randy Turner <[email-masked]>
Date: Wed, 10 Jun 1998 09:59:22 -0700

>does the server know which lpt port number to use.

In practical application, the server would never return a resource
identifier that specified a transport to which the client had not already
used to contact the server. And the forwarding scenario isn't realistic,
and also outside the scope of IPP.

>the URI I cannot know how to change them from one transport to another

This isn't supported by IPP either; this functionality would be some type
of gateway application that would have to administratively configured. The
way we have it defined now carves out middle 80% functionality we wanted to
achieve.

Randy