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