-----Original Message-----
From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
Sent: Thursday, April 16, 1998 3:41 PM
To: Harry Lewis; SISAACSON@novell.com
Cc: ipp@pwg.org; sdp@pwg.org
Subject: Re: IPP> Charter eyeglasses
I agree with Scott's interpretation. I think we chartered IPP to
solve=20
communication among clients, servers and printers, not just between
end=20
users and print servers.
I am concerned that SDP is a big mistake and will create yet another
protocol, incompatible with all others including IPP. I think that
it is=20
reasonable to borrow ideas from other protocols, such as TIPSI, but
I think=20
we should continue along the IPP path we started.
If IPP is not a reasonable embedded solution, I wonder why we are
just now=20
hearing that, nearly a year after we decided on the encoding. If
IPP is=20
really such a bad embedded solution, perhaps we should fix it before
we all=20
commit to supporting it and end up with support for both IPP and
SDP.
Bob Herriot
At 07:04 AM 4/16/98 , Harry Lewis wrote:
>Scott, I agree with your interpretation 100% and believe this is
the only
valid
>interpretation. Otherwise, I think the overall charter would have
been way
too
>limiting - even if this is where we ended up for v1. I put the
emphasis there
>to show how I think some must be reading the charter and the
conclusions they
>must have made.
>
>Harry Lewis - IBM Printing Systems
>
>
>
>
>SISAACSON@novell.com on 04/15/98 08:15:10 PM
>Please respond to SISAACSON@novell.com
>To: Harry Lewis/Boulder/IBM@ibmus, sdp@pwg.org, ipp@pwg.org
>cc:
>Subject: Re: IPP> Charter eyeglasses
>
>
>Harry,
>
>When I read:
>
>>>> Harry Lewis <harryl@us.ibm.com> 04/15/98 04:24PM >>>
>>The Internet Print Protocol is a CLIENT-SERVER type protocol which
>>should allow the server side to be either a separate print server
or
>>a printer with embedded networking capabilities.
>
>I assume CLIENT/SERVER in the distributed systems architecture
sense
>NOT in the literal CLIENT =3D PC and SERVER =3D file server/printer
server
hardware
>box sense.=A0 I see client/server meaning request/response rather
than
distribute
>object
>remote methods, IIOP, RMI stuff.
>
>In other workds, I am not confused into thinking end-user to file
server only
>(not server
>to device) when I see the term "client/server"
>
>Good reading of the charter thought, very helpful.
>
>Scott
>=20