I think the printer-uri inside application/ipp is of no use at all, unless we add another IPP Object to the model, call it a "Server", which demuxes requests by printer-uri IPP attribute. And then, I think printer-uri targets in requests should be Relative URIs, meaningful in the context of the Server.
The original proposal just asked for a way to identify Jobs inside requests. That makes sense for implementations that can only address Printers, not Jobs. But any implementation or transport layer should be able to address to the granularity of Printers, or else you have to invent IPP Servers.
The "job-id" is effectively a relative identifier, meaningful only in the context of the containing Printer. "job-uri" could be a Relative URI, too, when embedded in an IPP request addressed to a Printer.
The
> argument in favor of having it for HTTP was that a gateway would not have to
> alter the application/ipp data when passing it on.
>
> That assumption may be false if the client believed that the gateway is the
> printer and the gateway has to change the target printer as it passes the
> operation onward. Furthermore, the application/ipp encoding doesn't handle
> chunking of document data, so a gateway might still have to do some
> additional conversion.
>
> You may well be correct that the presence of a redundant printer-uri in the
> application/ipp data causes more problems than it solves.
>
> Bob Herriot
>
> At 02:50 PM 6/3/98 , Carl Kugler wrote:
> >>
> >> 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:kugler@us.ibm.com]
> >> Sent: Wednesday, June 03, 1998 11:21 AM
> >> To: ipp@pwg.org
> >> 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 <jkm@underscore.com>
> >> > > To: Randy Turner <rturner@sharplabs.com>
> >> > > Cc: ipp@pwg.org
> >> > > 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
> >> > > 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: jkm@underscore.com
> >> --
> >> > > -- Underscore, Inc. | Voice: (603) 889-7000
> >> --
> >> > > -- 41C Sagamore Park Road | Fax: (603) 889-2699
> >> --
> >> > > -- Hudson, NH 03051-4915 | Web:
> >> http://www.underscore.com --
> >> > >
> >> ----------------------------------------------------------------------