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

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

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

Alex Bochannek abochann at
Thu Jan 2 19:29:10 EST 1997

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.


------- Forwarded Message

Return-Path: cmanros at
Received: from ( []) by (8.6.12/CISCO.SERVER.1.1) with ESMTP id PAA09500 for <abochann at>; Thu, 2 Jan 1997 15:09:52 -0800
Received: from (alpha.Xerox.COM []) by (8.8.4/CISCO.GATE.1.1) with SMTP id PAA13478 for <abochann at>; Thu, 2 Jan 1997 15:09:21 -0800 (PST)
Received: from ([]) by with SMTP id <16901(8)>; Thu, 2 Jan 1997 15:08:25 PST
Received: from garfield ( by (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: < 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>
From: Carl-Uno Manros <cmanros at>
Subject: Re: IPP> Seperating the IPP protocol from the transport
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"


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

Best regards,


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
>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
>170 West Tasman Drive, Bldg. E Pager Email : abochannek at
>San Jose, CA 95134-1706, USA

------- End of Forwarded Message

More information about the Ipp mailing list