I think we agree in your last but one para (we just prhased it differently).
If we took printer-URI and job-URI out of IPP we would arrive at the
situation we both want. JOB-ID then identifies jobs.
With regards to your last point I think you hit a deeper problem: - the IPP
model is over-simple today. We do need a higher level construct in the
receiving agent (printer, server, peripheral, what ever you call it). Having
'printer' as the highest level is too restrictive. Even LPR allows for a
given transport endpoint to serve multiple named devices. You could say that
each printer has a different URL (or TCP port numher maybe). I thing we need
to be able to do things like enumerate printers (which you canot do with
some high level agent)
> -----Original Message-----
> From: Carl Kugler [SMTP:kugler@us.ibm.com]
> Sent: Thursday, June 04, 1998 12:27 PM
> To: ipp@pwg.org
> Subject: Re: IPP> Identifying jobs in requests
>
> > 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.
>
> 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
> > 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,...).
> >
>
> 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.