> 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)
IPP originally had a Server object in the model. Looking at the archives from March and May 1997, the group consensus apparently was that the Server itself had no important attributes or operations, so didn't need to be an addressable entity in IPP, and so should be removed from the model. Certainly, in the current model, a single software server might support multiple Printers (distinguished, by, e.g., a segment in the "abs_path" of the printer URIs). I agree that there is no way (in IPP) to invoke an operation like Enumerate-Printers on such a server, but the group considered this and decided it wasn't needed. The discussion was pretty spread out, but some of it appears in ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/minutes/970514-model-minutes.txt
- Carl
>
> > -----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.
>
>