IPP> IPP and the IESG
don@lexmark.com Mon, 06 July 1998 19:08 UTC
Delivery-Date: Mon, 06 Jul 1998 15:08:37 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1])
by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA27823
for <ietf-archive@ietf.org>; Mon, 6 Jul 1998 15:08:36 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30])
by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA04746
for <ietf-archive@cnri.reston.va.us>; Mon, 6 Jul 1998 15:10:56 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com
(8.7.5/8.7.3) with SMTP id PAA29435 for <ietf-archive@cnri.reston.va.us>;
Mon, 6 Jul 1998 15:08:34 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Mon, 6 Jul 1998 15:03:05 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id
PAA28863 for ipp-outgoing; Mon, 6 Jul 1998 15:01:37 -0400 (EDT)
From: don@lexmark.com
Message-Id: <199807061901.AA04631@interlock2.lexmark.com>
X-Lotus-Fromdomain: LEXMARK@LEXMTA
To: ipp@pwg.org
Date: Mon, 6 Jul 1998 14:24:39 -0400
Subject: IPP> IPP and the IESG
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipp@pwg.org
Three points on this issue: #1. I think Ron Bergman said it best when he said: "Why is HTTP not HTTP when the content-type is IPP?" #2. Keith Moore is wrong when he said: "Obviously, HTTP is a general purpose file transfer protocol. But printing is not the same as file transfer." Why is printing not just another case of file transfer? We already have many ways of doing file transfers: - ftp - tftp - smtp - http - etc. Perhaps the IPP group was a little smarter than so many of these other groups that had perhaps an NIH attitude and created yet another file transfer protocol. Rather than clog the net with another protocol that must be dealt with, we used an existing protocol and simply tagged our content appropriately (application/IPP.) Many printers today use TFTP or FTP to accept print jobs. Given some setup (which all file transfer protocols do at least to some extent), printing is really just another case of file transfer, i.e. I have a file and I want to send it to device "P". In the print case, the file is "transferred to paper" while in the Web case, the file is "transferred to the screen" and in the FTP case, the file is usually "transferred to disk." What is done with the content is irrelevant to the discussion, but it is still a file transfer. #3. Firewalls are not the issue, network infrastructure is. One of the major reasons we chose HTTP as the transport for application/ipp was the existing network infrastructure. I'll agree that firewalls are a part of that infrastructure, so are proxies, caches, etc. By transporting application/ipp on HTTP, we can take advantage of that infrastructure to speed the roll-out of IPP. Given that the vast majority of firewalls can filter on port(631) and/or content type (application/IPP), I content we are not try to "punch through" firewalls. If we were trying to do that, we would need to use port 80 and application/text or something else that couldn't be distinguished from normal web content. ********************************************** * Don Wright don@lexmark.com * * Product Manager, Strategic Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * **********************************************
- IPP> IPP and the IESG don
- RE: IPP> IPP and the IESG Rich Gray
- IPP> Re: IPP and the IESG Keith Moore