I meant 'odd' in a very specific way. IPP is INTERNET Printng Protocol - USB
is not normally considered as an Internet transport. The Internet is, after
all, a TCP/IP network.
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 at us.ibm.com]
> Sent: Friday, April 03, 1998 11:19 PM
> To: ipp at pwg.org> Cc: Roger K Debry; CGordon at wal.osicom.com; don at lexmark.com;
>rturner at 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 at pwg.org on 04/03/98 03:25:05 PM
> Please respond to ipp-owner at pwg.org> To: rturner at sharplabs.com, don at lexmark.com, CGordon at wal.osicom.com> cc: Ipp at pwg.org, Roger K Debry/Boulder/IBM at 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 at wal.osicom.com]
> > Sent: Friday, April 03, 1998 1:57 PM
> > To: 'don at lexmark.com'; rturner at sharplabs.com> > Cc: Rdebry at Us.Ibm.Com; Ipp at 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 at lexmark.com [SMTP:don at lexmark.com]
> > > Sent: Friday, April 03, 1998 4:22 PM
> > > To: rturner at sharplabs.com> > > Cc: Rdebry at Us.Ibm.Com; Ipp at 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 at lexmark.com *
> > > * Product Manager, Strategic Alliances *
> > > * Lexmark International *
> > > * 740 New Circle Rd *
> > > * Lexington, Ky 40550 *
> > > * 606-232-4808 (phone) 606-232-6740 (fax) *
> > > **********************************************
> > >
>>>