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
Return-Path: cmanros at cp10.es.xerox.com
Received: from beasley.cisco.com (beasley.cisco.com [171.69.2.135]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id PAA09500 for <abochann at nacho.cisco.COM>; Thu, 2 Jan 1997 15:09:52 -0800
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by beasley.cisco.com (8.8.4/CISCO.GATE.1.1) with SMTP id PAA13478 for <abochann at cisco.com>; Thu, 2 Jan 1997 15:09:21 -0800 (PST)
Received: from mailhost.cp10.es.xerox.com ([13.240.124.12]) by alpha.xerox.com with SMTP id <16901(8)>; Thu, 2 Jan 1997 15:08:25 PST
Received: from garfield (garfield.cp10.es.xerox.com) by mailhost.cp10.es.xerox.com (4.1/SMI-4.1)
id AA15550; Thu, 2 Jan 97 14:23:34 PST
Received: from cpq5100-26 by garfield (SMI-8.6/SMI-SVR4)
id PAA20342; Thu, 2 Jan 1997 15:06:41 -0800
Message-Id: <3.0.32.19970102150448.009205b0 at garfield>
X-Sender: cmanros at garfield
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 2 Jan 1997 15:04:49 PST
To: Alex Bochannek <abochann at cisco.com>
From: Carl-Uno Manros <cmanros at cp10.es.xerox.com>
Subject: Re: IPP> Seperating the IPP protocol from the transport
mechanism.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 : abochannek at cisco.com>170 West Tasman Drive, Bldg. E Pager Email : abochannek at beeper.cisco.com>San Jose, CA 95134-1706, USA
>>
------- End of Forwarded Message