I do not see anybody trying to LIMIT IPP. All I see are people (including
me) pointing out its limitiations - this is not the same thing at all.
> -----Original Message-----
> From: Harry Lewis [SMTP:harryl@us.ibm.com]
> Sent: Friday, April 03, 1998 11:19 PM
> To: ipp@pwg.org
> Cc: Roger K Debry; CGordon@wal.osicom.com; don@lexmark.com;
> rturner@sharplabs.com
> Subject: RE: IPP> Host to device
>
> I disagree that it would be odd to see IPP over other transports. Why
> would
> that be any less desirable than, say, TIPSI over USB? What is odd, to me,
> is
> for a standards group to invent one protocol and not deploy it (TIPSI),
> then,
> later, invent another (IPP) and try to limit (rather than enhance) it,
> trying
> to substitute the (now) older solution in it's place. Roger's observation
> is
> that, what makes TIPSI transport independent, is the packet structure,
> with
> continuation flag, ACKs and the ability to interleave commands (like
> CANCEL),
> not the command/query definitions themselves (which have been superseded
> by
> IPP). Randy is evolving a specific mapping to TCP/IP which addresses these
> issues as well (chunking, separate channel...). I don't see what is wrong
> with
> either approach.
>
> Harry Lewis - IBM Printing Systems
>
>
>
>
> ipp-owner@pwg.org on 04/03/98 03:25:05 PM
> Please respond to ipp-owner@pwg.org
> To: rturner@sharplabs.com, don@lexmark.com, CGordon@wal.osicom.com
> cc: Ipp@pwg.org, Roger K Debry/Boulder/IBM@ibmus
> Subject: RE: IPP> Host to device
>
>
> Good point - it would look very odd to have IPP for USB.
>
> Also odd would be to have two IPP implmentations on TCP/IP - HTTP and
> direct
> TCP/IP.
>
> In retrospect the correct thing to have done was to produce a mapping of
> TIP/SI onto HTTP. Ie. HTTP is just another transport layer.
>
> > -----Original Message-----
> > From: Gordon, Charles [SMTP:CGordon@wal.osicom.com]
> > Sent: Friday, April 03, 1998 1:57 PM
> > To: 'don@lexmark.com'; rturner@sharplabs.com
> > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org
> > Subject: RE: IPP> Host to device
> >
> > Given that IPP is the Internet Printing Protocol, do we really need to
> > support anything else besides TCP/IP? Is the IPP working group even
> > mandated to worry about non TCP/IP environments?
> >
> > --- Charles
> >
> > > -----Original Message-----
> > > From: don@lexmark.com [SMTP:don@lexmark.com]
> > > Sent: Friday, April 03, 1998 4:22 PM
> > > To: rturner@sharplabs.com
> > > Cc: Rdebry@Us.Ibm.Com; Ipp@pwg.org
> > > Subject: RE: IPP> Host to device
> > >
> > >
> > > Randy:
> > >
> > > My biggest concern is that your proposal is TCP/IP only. Is does not
> > > solve
> > > the problem for printers connected to servers via:
> > >
> > > - Parallel
> > > - Serial
> > > - USB
> > > - 1394
> > > - IPX/SPX
> > > - AppleTalk
> > > - DLC/LLC
> > > - etc., etc., etc.
> > >
> > > If I'm going to use TCP/IP then I might as well go ahead with the HTTP
> > > based implementation. You don't provide more status and control or
> > > anything else that really buys me anything other than a slightly
> > > lighter
> > > transport. It's just not work the trouble for the return on
> > > investment.
> > >
> > > Don
> > >
> > > **********************************************
> > > * Don Wright don@lexmark.com *
> > > * Product Manager, Strategic Alliances *
> > > * Lexmark International *
> > > * 740 New Circle Rd *
> > > * Lexington, Ky 40550 *
> > > * 606-232-4808 (phone) 606-232-6740 (fax) *
> > > **********************************************
> > >
>
>
>