IPP> Why must IPP be transport-independent?

IPP> Why must IPP be transport-independent?

Josh Cohen joshco at microsoft.com
Thu Jun 4 23:17:21 EDT 1998


I dont see exactly what the issue is.
Having a job-uri, or using URIs for naming and identification
doesnt link the IPP protocol to HTTP at all.  URIs are
a fine way to manage a unique namespace, even if your
not using HTTP.  
Technically, if IPP is deployed over any other protocols,
you can still use URIs.  Lets say, for example, that you
deployed IPP over FTP or SMTP.   If you did this then
your job-uri would be ftp://host/job or mailto:job at host, 
respectively.
If you used IPP over another protocol, you could likely
define a new URI scheme to represent it.




> -----Original Message-----
> From: Paul Moore [mailto:paulmo at microsoft.com]
> Sent: Thursday, June 04, 1998 11:43 AM
> To: 'Jay Martin'; ipp at 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 at underscore.com]
> > Sent:	Thursday, June 04, 1998 11:28 AM
> > To:	ipp at 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 at 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,...).



More information about the Ipp mailing list