> -----Original Message-----
> From: Jay Martin [SMTP:jkm@underscore.com]
> Sent: Thursday, June 04, 1998 11:28 AM
> To: ipp@pwg.org
> 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 -
> 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.
> 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,...).