IPP> Why must IPP be transport-independent?

IPP> Why must IPP be transport-independent?

Jay Martin jkm at underscore.com
Thu Jun 4 20:03:02 EDT 1998


Carl-Uno,


I'm a bit confused about who you're agreeing with here.


The text that you've quoted is from me, not Harry.


I read Harry's response to my posting as being in
mild disagreement, citing that the charter claimed
that IPP was supposed to be a generically usable
network printing protocol.


Are we to read that you've come to the position that
maybe IPP should be explicitly relegated for use over
HTTP, and not attempt to be transport-independent?
Or did I interpret your message incorrectly?


	...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   --
----------------------------------------------------------------------




Carl-Uno Manros wrote:
> 
> At 12:48 PM 6/4/98 PDT, Harry Lewis wrote:
> >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.
> 
> Harry,
> 
> I think I start agreeing with you on this one. My recollection is that we
> got this as part of our discussion to use a MIME part for the encoding.
> MIME purists have stated that all MIME types MUST be transport independent.
> 
> I think that having an object that can be mapped to another transport has
> its virtues, but I was never convinced that it would ever make sense to
> actually send the "application/ipp" object over email. Alternative
> transports that make sense to me are things like the emerging HTTP-NG
> protocol, and that is most likely able to handle URLs the same way as HTTP
> does today.
> 
> If somebody REALLY wants to send "application/ipp" over email, then they
> would need to have an email address in the place where we are using the
> HTTP URIs anyway, and I expect that such a mailbox would be dedicated to
> the IPP printer and know what to do with messages it receives. In short,
> new transport, new addressing scheme.
> 
> In summary, I think we should remove any redundant URI information in the
> "application/ipp", it seems to cause more confusion than what it is worth.
> 
> Carl-Uno
> Carl-Uno Manros
> Principal Engineer - Advanced Printing Standards - Xerox Corporation
> 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
> Phone +1-310-333 8273, Fax +1-310-333 5514
> Email: manros at cp10.es.xerox.com



More information about the Ipp mailing list