Subject: Re: IPP> Identifying jobs in requests

From: Jay Martin <[email-masked]>
Date: Wed, 03 Jun 1998 12:32:19 -0400

Randy Turner wrote:
> 
> We use URIs to identify IPP objects. If we want IPP to maintain
> transport-independence, then we will always need to have some type of valid
> URI denoting the target of an IPP request inside our protocol.

Not necessarily.  Sure, in the case of a demultiplexing front-end,
it would be necessary to have the target embedded in the protocol
message, but not necessary for single-Printer implementations.

I don't have a problem with embedding the target URI in the PDU,
but if we get into a big mess with regard to reconciling a similar
target in the outer/lower transport level (eg, HTTP), then we might
want to consider pulling out the embedded target URI.

It would be nice to hear from others on this topic.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Wed, 03 Jun 1998 18:25:00 -0400

Yes, this is what I was envisioning.  Thanks, Randy.

	...jay

Turner, Randy wrote:
> 
> The demux wasn't my idea, I was just clarifying what I thought Jay was
> suggesting...however, the URI itself is self-demux'ing. As you move left
> to right parsing a URI, you are basically performing a kind of
> demultiplexing, with one or more layers each handling a portion of the
> URI string. Its not hard to envision any number of demux'ing techniques
> using URIs in both HTTP and IPP headers.
> 
> Sorry I missed the carnage at the teleconference ;)...hope to see the
> minutes.
> 
> Randy
> 
>         -----Original Message-----
>         From:   Carl Kugler [SMTP:[email-masked]]
>         Sent:   Wednesday, June 03, 1998 2:50 PM
>         To:     [email-masked]
>         Subject:        Re: RE: IPP> Identifying jobs in requests
> 
>         >
>         > I think Jay was talking about a lower-layer demux than what
> you are
>         > talking about. The kind of demux that might be performed by a
>         > CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the
> data to a
>         > core IPP processing component.
>         >
>         > Randy
>         >
> 
>         How does placing a URI denoting the target of an IPP request
> inside our protocol (as an IPP attribute) facilitate this kind of demux?
> 
>         >
>         >       -----Original Message-----
>         >       From:   Carl Kugler [SMTP:[email-masked]]
>         >       Sent:   Wednesday, June 03, 1998 11:21 AM
>         >       To:     [email-masked]
>         >       Subject:        Re: IPP> Identifying jobs in requests
>         >
>         >       >
>         >       > The demultiplexing front-end is not IPP, and is
> therefore some
>         > type of
>         >       > "transport-helper". While the IPP protocol document
> must stand
>         > on its own,
>         >       > independent of any such transport, and therefore
> identifiers
>         > within the
>         >       > protocol would still be mandatory ( Of course, my
> argument is
>         > entirely
>         >       > based upon the WG's decision that IPP must be
> transport
>         > independent ).
>         >       >
>         >       > Randy
>         >       >
>         >
>         >       Randy-
>         >
>         >       If the demultiplexing front-end is not IPP, how is it
> able to
>         > read IPP attributes?
>         >
>         >       - Carl
>         >       >
>         >       > ----------
>         >       > > From: Jay Martin <[email-masked]>
>         >       > > To: Randy Turner <[email-masked]>
>         >       > > Cc: [email-masked]
>         >       > > Subject: Re: IPP> Identifying jobs in requests
>         >       > > Date: Wednesday, June 03, 1998 9:32 AM
>         >       > >
>         >       > > Randy Turner wrote:
>         >       > > >
>         >       > > > We use URIs to identify IPP objects. If we want
> IPP to
>         > maintain
>         >       > > > transport-independence, then we will always need
> to have
>         > some type of
>         >       > valid
>         >       > > > URI denoting the target of an IPP request inside
> our
>         > protocol.
>         >       > >
>         >       > > Not necessarily.  Sure, in the case of a
> demultiplexing
>         > front-end,
>         >       > > it would be necessary to have the target embedded in
> the
>         > protocol
>         >       > > I don't have a problem with embedding the target URI
> in the
>         > PDU,
>         >       > > but if we get into a big mess with regard to
> reconciling a
>         > similar
>         >       > > target in the outer/lower transport level (eg,
> HTTP), then
>         > we might
>         >       > > --  JK Martin               |  Email:
> [email-masked]
>         > --
>         >       > > --  Underscore, Inc.        |  Voice:   (603)
> 889-7000
>         > --
>         >       > > --  41C Sagamore Park Road  |  Fax:     (603)
> 889-2699
>         > --

---

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