Subject: IPP> Identifying jobs in requests

From: Paul Moore <[email-masked]>
Date: Thu, 4 Jun 1998 10:58:28 -0700

It seem to me that the fundamental question comes down to - should
the IPP protocol form, transmit and use information that is specific to the
underlying transport. 

	We have chosen to use URI as our way of identifying endpoints. The
assumptions we make about these URIs (there actual syntax is irrelevant)
are:-
	a) an agent knows how to form them
	b) the only thing an agent may do with a URI it receives to it is to
pass it to its underlying transport. This means that the creator of the URI
MUST use the same URI forming convention as that which will be used by the
receivers transport stack (ie. this is not a private issue for a given
implementation). It also means that the receiver may not look at the URI to
infer any deeper meaning (because that is a private issue for the sending
implementation).
	This last restriction made us invent job-id. We moved to explicitly
stating in IPP the way of identifying an endpoint. 
	The real problem is that we end up with leakage from the transport
up into the IPP layer. I cannot blindly forward requests from
IPP-on-protocolX to IPP-on-protocolY. I have to find all the URIs and change
them on the fly.
	There is another problem that assumpion b causes. It assumes that a
printer knows how to form an address (URI) that makes sense in the clients
transport stack. This is true for HTTP but not true (or certainly
non-trivial) for other transports.

	I would propose that we use an adressing scheme that corresponds to
the transport endpoint only. We then specifiy in IPP the ways of identifying
the logical object that we wish to talk to (printer-ID, Job-ID,...).

---

From: "Carl Kugler" <[email-masked]>
Date: 4 Jun 1998 19:26:44 -0000

> 	We have chosen to use URI as our way of identifying endpoints. 

Could you define "endpoint" in this context?  Is it equivalent to an IPP "target"?  Or are you using the term in the TCP sense?

>The

Or you could invert this, and put the target addressing outside the IPP payload.  Then you can forward requests and/or rewrite target addresses without ever opening the "envelop",  to use Scott's postal analogy.  For this to work, any internal target identifiers would have to be relative (like job-id).

It seems to me that your scheme would require the transport endpoint to be some kind of IPP Server that could route requests to Printers based on embedded printer-ID.  Then you've added another layer of indirection to the IPP model.