I am concerned that SDP is a big mistake and will create yet another=20
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