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@pwg.org on 06/10/98 07:46:14 PM
Please respond to owner-ipp@pwg.org
To: masinter@parc.xerox.com
cc: ietf-http-ext@w3.org, ipp@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@ics.uci.e= du) University of California, Irvine, CA 92697-3425 fax:+1(949)824-1= 715 http://www.ics.uci.edu/~fielding/
=