Subject: Re: IPP> regarding "ipp:" (I spoke too soon...)

From: "Scott Isaacson" <[email-masked]>
Date: Thu, 02 Jul 1998 15:19:20 -0600

Keith,

I find the following process very ineffective:

1. IESG charters IPP WG in 3/97 after a well attended BOF 12/96.  
2. The WG has always been well staffed and work has progressed within the working group at a very good rate.  We were essentially done at the end of 97.
3. The working group has reached consensus and produced a set of drafts that meet the objectives of the charter.
4. The decision to reuse HTTP/1.1 has been on the table (IPP WG email discussion list, IPP drafts) for over a year now.  There was NEVER any discussion in the working group meetings in Munich, DC, and/or LA that IPP should not be layered on top of HTTP/1.1.  The only question was POST vs PRINT.  Both of which implied layering on top of HTTP/1.1  For a year we have said that IPP opertions would be use the "http:" scheme.
5. The working group had final call in 12/97.  All comments were addressed.
6. The IESG held IEFT wide final call.  There were virtually NO comments on the mailing list.  All comments were addressed.

Now, here is the real killer step:

7. 5  months after the end of the IESG final call on the IPP documents, we start to hear that "You MUST do it this way or else it will not be approved."  Such comments were REQUIRED a year ago - they seem disruptive now.

I don't buy the arguments about "layering is bad".  Although not optimal, the argument is that re-using HTTP was a good thing becuase of the leveraging and growth path of HTTP.  HTTP is already being used for network attached printers and for print servers in a big way - it is already deployed where it needs to be.  I do understand that IPP needs to be distinguishable, therefore the default port is a great idea along with an obvious content-type.  If every protocol did its own infrastructure, security, naming, identity, distribution model, header definitions, etc., the world would be a mess.  In my mind, it is either HTTP/1.1 for leveraging exiting protocol stack rather than requiring new ones, or not.  I would hate to have all of the disadvantages of using HTTP with none of the advantages.  At least with re-use, you get some or all of the advantages.

Scott

************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121 
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: [email-masked]
web: http://www.novell.com
************************************************************

---

From: Josh Cohen <[email-masked]>
Date: Thu, 2 Jul 1998 14:27:07 -0700

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Thursday, July 02, 1998 1:26 PM
> To: Tom Hastings
> Cc: Keith Moore; Paul Moore; [email-masked]; [email-masked]
> Subject: Re: IPP> regarding "ipp:" (I spoke too soon...) 
> 
> There's a long tradition in IETF of reusing and/or adapting existing
> technology, so there's no problem with that per se.  But there are 
> several problems with overloading a new protocol on top of existing 
> web *services*.  And the idea that IPP should be able to tunnel
> through firewalls "by default" - thus overriding local site policy -
> does great harm to the overall Internet architecture.
> 
As you know, I totally agree with the policy issue, as that has
been the crux of my argument in the POST draft issues.  
However, I feel strongly that HTTP is a valuable platform
to be built upon in a layered or substrate model.  I would
characterize IPP as a "service" within the http framework.
(You can pick better words for service and framework, but thats
just picking nits).
I beleive that for services within HTTP the best way to differentiate
them is to use a new METHOD.  Using a new method maintains the HTTP
message format and transport scheme (http://) but is easily filterable.

I think one of the main points here is that when traversing some
infrastructure,
wether it be end-node embedded web servers or application layer
proxy/firewalls,
does each node have to fully understand the IPP protocol?
My opinion is that they do not.  By being able to easily identify the
"service"
,via the METHOD in my example, the node has enough information to enforce a
security policy by rejecting or allowing it and can hand the message off to
an method handler for IPP to process it.
In the same way the TCP transport identifies different protocols by their
port numbers, the HTTP application transport can identify different services
by their methods.  Intermediate nodes dont necessarily need to understand
the message body, just the way that proxy servers today have no knowledge
of HTML in typical web traffic.
In cases where it is wise to have the intermediate nodes understand
the content or semantics of an extension we address that in the form
of the proposed Mandatory syntax.

To sum up, HTTP as an application tansport layer provides added
functionality
compared to TCP which allows services running over HTTP to avoid reinventing
an various wheels (authentication, mime-content body, caching, pipelining,
message versioning (via etags), infrastructure traversal, filtering, etc)
like if it was to run over TCP.

In cases where the http functionality "wheels" are appropriate for a
service, it makes sense to look at HTTP as an application transport service
and to build upon it.  When it does not, a "new" transport protocol should
be
used.  

The IPP authors chose to build on HTTP for good reason, IMHO, for many of
features I mentioned above.

An easy way to identify the IPP service is via a new method, it provides
easy filtering and doesn not require IPP specific knowledge at each node
in the infrastructure as a new scheme would.

Josh Cohen

---

From: [email-masked]
Date: Fri, 3 Jul 1998 17:55:48 -0700 (PDT)

When the first discussions about the URI/URL and related transport
issues first came up,  there were serious discussions and ranting
arguments about the need to 'make as few changes in the HTTP protocol
to allow printing from browsers',  and why we could not change
the URI/URL scheme.

At the time I pointed out the problems with trying to alias the
HTTP port/service to the IPP port/service and was roundly trashed
for this ... umm... heretical suggestion.

I would now like to comment that adding a new protocol/method such
as ipp: is nothing major, and has been accommodated by most browser
developers in a pretty trivial way.

How and why do you ask?  Look at Real Video and Real Audio.

Try feeding 'npm://<realaudio server>:<port>/realaudiofile.ra'
to your browser,  and VOILA!  it works.  Sorta.

Based on existing 'state of the art' and 'current technology', I
find the argument of the difficulty of using ipp: in the URL rather
hard to swallow,  but did not want to rock the boat so close to
closure on the standard.

Note carefully that I did not say that it works CLEANLY, just that
it works.  Of course,  somebody would have to write a program to
assist the Internet Explorer (I gather that this is now a generic
term for browser) to connect to and send the file to the server,
but this is clearly akin to distributing a print driver for a
printer...  Something that most printer manufacturers seem to regard
as part of the cost of doing business.

Patrick Powell

Patrick Powell                 Astart Technologies,
[email-masked]            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   619-874-6543 FAX 619-279-8424 
LPRng - Print Spooler (http://www.astart.com)