Subject: IPP> IPP and the IESG

From: [email-masked]
Date: Mon, 6 Jul 1998 14:24:39 -0400

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                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: Keith Moore <[email-masked]>
Date: Mon, 06 Jul 1998 19:41:18 -0400

Don,

It's really very simple.

Most of the time HTTP is used to fetch web pages or to upload form data.  
Printing is viewed by IESG to be sufficiently different than either
of these two that it needs to be distinguished from ordinary HTTP, both by
having a different port # and a different URL type. 

Making such judgements is part of IESG's job.    

I refer you to RFC 2026, section 6, first paragraph:

6.  THE INTERNET STANDARDS PROCESS

   The mechanics of the Internet Standards Process involve decisions of
   the IESG concerning the elevation of a specification onto the
   standards track or the movement of a standards-track specification
   from one maturity level to another.  Although a number of reasonably
   objective criteria (described below and in section 4) are available
   to guide the IESG in making a decision to move a specification onto,
   along, or off the standards track, there is no algorithmic guarantee
   of elevation to or progression along the standards track for any
   specification.  The experienced collective judgment of the IESG
                   ***********************************************
   concerning the technical quality of a specification proposed for
   *****************************************************************
   elevation to or advancement in the standards track is an essential
   ******************************************************************
   component of the decision-making process.
   ****************************************

Keith