Harry Lewis - IBM Printing Systems
owner-ipp@pwg.org on 06/04/98 12:34:54 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org
cc:
Subject: IPP> Why must IPP be transport-independent?
After reading Paul Moore's posting (below), it appears
that we are digger ourselves a deeper and deeper hole
to fall into.
Must IPP be transport-independent?
I say "No". IPP stands for "Internet Printing Protocol",
not something like "Generic Printing Protocol", or "Universal
Printing Protocol". It was designed for use on the Internet.
Sure, there are some in the IPP WG who believe IPP can
and *should* become the single, all-encompassing printing
protocol for use in almost any environment.
I (and others) say "hogwash". Microsoft and Northlake Software
have done a good job in delineating areas in which the IPP
design falls very short in providing the kind of session-
oriented protocol to achieve the kinds of capabilities that
already exist in TIP/SI, CPAP and others.
If HTTP is going to be the first and primary reference
implementation of IPP (damn the nay-sayers...), then why
can't we just tie IPP onto HTTP (semantics, syntax et al)
and be done with it?
Let the SDP project deal with other non-HTTP-oriented
requirements. We'll just strive to make the mapping
from IPP to SDP as easy and painless as possible.
...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 --
----------------------------------------------------------------------
Paul Moore wrote:
>
> It seem to me that the fundamental question comes down to - s=
hould
> 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 irreleva=
nt)
> are:-
> a) an agent knows how to form them
> b) the only thing an agent may do with a URI it receives to i=
t is to
> pass it to its underlying transport. This means that the creator of t=
he URI
> MUST use the same URI forming convention as that which will be used b=
y the
> receivers transport stack (ie. this is not a private issue for a give=
n
> 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 sen=
ding
> implementation).
> This last restriction made us invent job-id. We moved to expl=
icitly
> stating in IPP the way of identifying an endpoint.
> The real problem is that we end up with leakage from the tran=
sport
> 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 cl=
ients
> 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 correspo=
nds to
> the transport endpoint only. We then specifiy in IPP the ways of iden=
tifying
> the logical object that we wish to talk to (printer-ID, Job-ID,...).
=