Subject: Carl-Uno Manros: Re: IPP> Seperating the IPP protocol from the transport mechanism.

From: Alex Bochannek <[email-masked]>
Date: Thu, 02 Jan 97 16:29:10 PST

Carl-Uno suggested I send this to the list. One comment I can add is
that an implementation of a server in TCP listen state that forks upon
connect is about one page of C-code in Stevens' UNIX Network
Programming book.

Alex.

------- Forwarded Message

Date: Thu, 2 Jan 1997 15:04:49 PST
To: Alex Bochannek <[email-masked]>
From: Carl-Uno Manros <[email-masked]>
Subject: Re: IPP> Seperating the IPP protocol from the transport
  mechanism. 

Alex,

this looks better than I had expected. Perhaps you want to send this
information to the IPP list for their information.

Best regards,

Carl-Uno

At 04:50 PM 12/18/96 PST, you wrote:
>> Alex,
>> 
>> I believe that most of us in the IPP project are a bit unfamiliar with
>> things that run directly on top of TCP and do not know what is required and
>> what we would lose by not using IP. E.g. could you run such a new protocol
>> in a Web browser the same way as you can run FTP and a number of other
>> protocols today? How about the security aspects?
>
>It really is dead simple. All you need is a server that runs on a
>system with the proper port (I think you suggested 380) in listen
>mode. When a client connects to it, you can either fork a new process
>or just block the port depending on how you want to implement it. The
>socket pair at that point uniquely identifies the IPP stream and all
>your software has to do is parse the IPP commands. It would be helpful
>to define delimiters between messages and you could even use the MIME
>headers (without SMTP).
>
>You can make parsing easier by mapping IPP commands to short tokens
>like you do in SMTP (HELO, EXPN, DATA, QUIT, that kinda
>stuff). Otherwise you need to Operation-tokens as defined in the
>draft.
>
>The way to implement it in a Web browser (or any other client for that
>matter) is just like the ftp://, gopher://, ldap://, mail://, news://,
>or even http:// access methods are implemented. Your browser vendor
>implements a new access module and then you have use the straight
>protocol. There is no reason though not allow for an http to ipp
>GATEWAY (pretty common for ldap right now). This way you can submit
>jobs via forms like you have been proposing and see the IPP responses
>come back to you on a Web page.
>
>As far as what you loose: nothing! You have a bidirectional clear data
>stream with delivery guarantees. And for firewalls, I most definitely
>agree that making the protocol invisible is a bad idea. But keep in
>mind that a TCP proxy (which is one of the most commonly used setups)
>will work without a problem.
>
>--
>Alex Bochannek                 Phone & Fax : +1 408 526 51 91
>Senior Network Analyst         Pager       : +1 408 485 90 92
>Engineering Services           Alpha Pager : (800) 225-0256 PIN 104536
>Cisco Systems, Inc.            Email       : [email-masked]
>170 West Tasman Drive, Bldg. E Pager Email : [email-masked]
>San Jose, CA 95134-1706, USA
>
>

------- End of Forwarded Message