Roy, thanks for commenting on some of the last remaining issues with IP=
P and
the current recommendation of our area director to specify a default po=
rt and a
new name for the URI scheme. I am most likely not as knowledgeable as y=
ou
regarding HTTP, it's design and various uses, so I would like to ask fo=
r some
clarifications and share some observations.
You said
>On the contrary, the forwarding function is based on the URI,
>not on the method or media type. The filtering function
>(or, more accurately, the routing function) is based on
>everything in the request.
I should interpret this as "anything in the request might be useful for=
filtering", right? I don't think I should read this as "all (filtering)=
routers
always use everything in the request as a filter", right?
Larry said
>In the case of IPP, it is perfectly adequate to filter on
>content-type, since all IPP content is carried in application/IPP.
To which you replied
>There is nothing special about Internet printing that requires
>independent firewall semantics.
Since media-type is part of "everything in the request"... why do you r=
efer to
this recommendation as "independent firewall semantics"? It seems valid=
for
Larry to point out that mime-type is consistent for IPP and, therefore,=
can be
considered a reliable filter.
I don't think anyone is recommending the treatment of POST to an HTTP s=
erver
(acting as a print server) any differently than POST directly to a prin=
ter or
differently from any POST to any HTTP server, for that matter. Just, if=
you
want to filter on mime-type, you can.
You wrap up with two additional points (paraphrased):
1. Because IPP is mapped to HTTP, it does not allow
selective access to the printer's resources.
IPP allows access to resources such as configuration or job information=
,
regardless of the protocol mapping. Is this what you are referring to? =
What
other resources of the printer do you want to access independently? Are=
you
thinking of things like firmware refresh or font libraries?
2. Control of network resource access is already
provided at the URI level and in the underlying
protocol layers upon which HTTP takes place.
Right... doesn't this confirm or choice of HTTP as the initial mapping?=
Harry Lewis
owner-ipp at pwg.org on 06/10/98 07:46:14 PM
Please respond to owner-ipp at pwg.org
To: masinter at parc.xerox.com
cc: ietf-http-ext at w3.org, ipp at pwg.org
Subject: IPP> Re: On the harm of adding new methods
I disagree with some of Larry's points. The design of HTTP was intende=
d
for method extension whenever there is a standardizable semantics
that can be shared between client and server (and, most importantly,
between those agents and any intermediaries that may be between them).
>There are two functions of a proxy: filtering and forwarding.
>A filter decides whether or not to accept a request, and a forwarder
>actually forwards the request and processes the result; forwarding
>implements caching, protocol translation, tunneling, while filtering
>is generally a binary "allowed" or "not allowed". There are some
>forwarders that do rewriting in lieu of filtering (allow but modify).
And also those that do transformation and forwarding, though that's
not an issue here. Basically, there exist active and passive
intermediaries.
>Forwarders MUST actually understand methods, because -- unfortunately =
--
>the meaning of HTTP headers and responses differ based on the method
>of the request (e.g., Content-Length for HEAD vs GET). Many forwarding=
>systems will not accept new methods gracefully.
Actually, that is only true for HEAD and GET -- all header fields have
the same meaning for all other methods. HEAD is the only method for
which Content-Length has a different meaning, and no new method can cha=
nge
the message length calculation. GET/HEAD is the only method for which
conditional request header fields have the 304 meaning, whereas for all=
other methods they have the 412 meaning. I can't think of any other
exceptions at the moment -- if any have been added in the past year
or so, they need to be removed.
HTTP/1.1 is designed to enable forwarding without understanding the
method semantics, provided that such forwarding fits within the securit=
y
policy set at the intermediary.
>Any new METHOD in HTTP is a serious modification to the protocol, beca=
use
>the forwarding function must be aware of it. A new content-type, howev=
er,
>can be as easily recognized in the filter layer as a new method, but
>requires NO changes to the forwarding function. Many filters already f=
ilter
>on content-type anyway.
On the contrary, the forwarding function is based on the URI, not on
the method or media type. The filtering function (or, more accurately,=
the routing function) is based on everything in the request. What you
are saying is that it is better for filtering to eliminate one of the
criteria by which an intermediary can do filtering, in this case the
one that is easiest to find and interpret quickly in an HTTP request.
I think that is a bad design when there are semantics that can be easil=
y
distinguished via the method.
>In the case of IPP, it is perfectly adequate to filter on content-type=
,
>since all IPP content is carried in application/IPP. The arguments for=
>adding a new method (that it is somehow 'easier' to filter on the firs=
t
>few bytes of the protocol) are specious because most filters that are
>looking at the protocol at all are looking at content-type. So the
>"firewall filtering" rationale just doesn't hold as a reason for addin=
g
>new methods.
Well, it seems I disagree with everyone on this part. There is nothing=
special about Internet printing that requires independent firewall
semantics. Nothing. A printer is a network resource that must be
protected like all other network resources -- as a resource. There is
no difference between sending a POST full of data to an HTTP server
acting as a printer gateway and sending a POST full of data to the
printer directly. Treating the two as being different violates one
of the basic principles of the Web architecture.
That does not mean we should add a PRINT method to the protocol.
PRINT does not say anything semantically interesting. Why should the
client care what mechanism is being used behind the curtains? Should t=
he
semantics need to change if the server is actually a pipeline like
client ---- proxy ----- fax ----- fax ---- printer
If you look at any modern operating system design, you will find such
differences abstracted away so that every application does not need
separate interface protocols for every device type. Why should the
Internet be any different?
RENDER would be a more semantically meaningful choice, since what the
client is saying is that it wants the service to render the data as
specified and then discard it. However, the reason for defining this
new method has nothing to do with firewall filtering.
The IPP design is poor because it conflates an intended action with
the transfer syntax of the data, thus reducing the normal mechanisms of=
allowing selective access to a printer's resources using any of the
independently defined security mechanisms of HTTP. While it may be
nice to think of Internet printing as a layered protocol on top of HTTP=
,
the result is something that is neither efficient nor capable of reusin=
g
many of the advantages of HTTP. Instead, printing should have been
designed as a service with a defined resource model; standard Web agent=
s
could then manipulate that resource model using the same protocols
as everyone else's resources. For those cases where data and control
information is to be sent in one action, an application-independent
transfer syntax should be used to group them (a la multipart/related).
Of course, there is nothing to prevent such an implementation from
coexisting with IPP, so I am not suggesting that IPP be changed at this=
time.
Attempting to isolate printer services from other services using any of=
the options suggested (new URI scheme, separate port, new method, obscu=
re
media type) is ultimately futile. None of these provide anything usefu=
l
in the way of securing access to resources; the first two in particular=
are a total waste of time since the "http" URI scheme is port-independe=
nt.
The only thing you accomplish is making the implementations more compli=
cated.
Control of network resource access is already provided at the URI level=
and in the underlying protocol layers upon which the HTTP communication=
takes place.
...Roy T. Fielding
Department of Information & Computer Science (fielding at ics.uci.e=
du)
University of California, Irvine, CA 92697-3425 fax:+1(949)824-1=
715
http://www.ics.uci.edu/~fielding/
=