> -----Original Message-----
> From: Paul Moore [mailto:paulmo@microsoft.com]
> Sent: Thursday, June 04, 1998 11:43 AM
> To: 'Jay Martin'; ipp@pwg.org
> Subject: RE: IPP> Why must IPP be transport-independent?
>
>
> One point - this is othogonal to much of the 'URI in the
> protocol' question.
> As job-id vs job-uri shows there are still areas where this
> is a problem
> even if we decide to only do IPP on HTTP.
>
>
> > -----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,...).