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

[Josh Cohen <[e-mail]>]

> -----Original Message-----
> From: Keith Moore [mailto:[e-mail]]
> Sent: Thursday, July 02, 1998 1:26 PM
> To: Tom Hastings
> Cc: Keith Moore; Paul Moore; [e-mail]; [e-mail]
> 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