[BXXPwg] IPP mapping onto bxxp

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Thu, 14 Jun 2001 23:39:49 -0700


> Is anyone working on mapping IPP onto bxxp?

i think that the large issue is that ipp is very carefully tailored to run
over http. it has a number of design features that are http-assumptive.

this doesn't mean that it can't be done or that it wouldn't be a good thing.
but, it wouldn't be a brief memo like the one for soap onto beep.

here's an example:

every couple of weeks robert herriot surfaces a draft which attempts to
define an effective multiplexing format for use in ipp. the motivation is
that a network printer may be unable to store an entire page of a compound
document internally before it can start rendering. a multiplexed approach
would allow the printer to get parts of the "container" document and parts
of the "components" (e.g., images) so that it can incrementally put the page
together.

everytime robert herriot surfaces the latest draft, someone responds that
the root problem deals with a protocol issue not an encoding issue. the
counter-response is usually to make the encoding more complex, e.g., by
adding more granularity or whatever.

in beep, it is trivial to solve a problem like this: the desktop establishes
a session with the printer and starts sending the pages of the "container"
document which contains references to the "components" via URIs. when the
printer needs to stop working on the container and start working on a
component, it requests the relevant URI over the same session.

another issue deals with asynchronous notifications from the printer back to
the desktop, which are hard to do with http, but easy to do with beep.

my point here is that the guys who did ipp developed a fine-crafted protocol
to work on top of what http gave them. you wouldn't get a lot of joy from
replacing "ipp.http" with "ipp.beep", if you're going to change things, then
you need to revisit some of the basic ipp mechanisms with beep in mind...

m/tr