This seems to come up again and again and seems like most everybody has =
decided that "the firewall" or "the proxy" argument can be successfully =
debated either way. The IPP WG did an "informal survey" over that past =
year that showed no influencing factors pushing the decision in either =
direction. A good survey would be very useful.
>2. Separate methods are certain not to introduce new constraints on HTTP,
>whereas using POST might do so.
This conclusion seems backwards to me. With new methods a new HTTP =
version must be defined or a an extension mechanism (PEP) must be defined =
on how to extend it. With POST, no such action is necessary.
>3. Separate methods are cleaner for existing servers to deal with. Using
>POST might cause unpredictable results from existing servers. (a
>controversial claim)
Again this claim seems backwards to me, note the controversial claim
>4. Using separate methods stays closer to the simple OO model of the Web,
>where operations are defined on resources.
I agree with the fact that separate methods stay closer to a simple OO =
model, but what is the
"OO model of the Web"? There definitely is not consensus on this. In the =
working group moving
to IIOP/RMI/DCOM has always been "shot down" pretty quickly. If we do =
this as OO, we need some better stability first. Note: The OMG Printing =
Facility is OO and that IDL shows a %100 mapping to IPP. So let's use =
IIOP not HTTP and the whole discussion about new methods vs POST is moot.
>5. It depends on your model of a web server. You can view a web server =
as
>a collection of objects, with methods defined on them, a la object-oriente=
d
>programming. Or you can view a web server as a collection
>of agents (computational entities), of which some serve documents, while
>others perform activities like "copy" or "server diff." In fact, there =
may
>be many agents capable of performing an activity, and a single agent may =
be
>capable of handling more than one type of activity. On the OO view of =
HTTP,
>an HTTP message is directed to an object (the
>Request-URI), which handles the method in the request message. On the =
agent
>view of HTTP, an HTTP message is directed to an agent (or a default HTTP
>agent), which then handles either the HTTP/1.1 style message or processes
>the command specified in the MIME type of the request message. The
>advantage of the Agent view is the range of capability of the agents =
isn't
>hardwired, and there may be many agents, with slightly different
>characteristcs, all active simultaneously in the same server. The
>advantages of the Object Oriented view stem from the fixed set of =
methods:
>this fixed set is understood better by existing Web technology (e.g.,
>caches), and can be used to implement a simple access control scheme
>(method x user --> ACL).
Again, I agree with this. However, I have been pushed back when I bring up =
the OO discussion within the IPP WG. The decisions have been made to not =
be so OO pure at this point in time.
>6. Separate methods are simpler and cleaner for server vendors to
>implement. (Some server implementors felt very strongly about this.)
Where any of the server implementors involved the embedded web server =
guys? Again, sounds like a controversial claim.
>7. It's easier to modify media types if we want to make changes later =
than
>it is to modify method definitions. (a controversial claim)
So, this argues for POST right?
>8. Access control today is based on methods, not on media types. (claim =
by
>an Apache implementor)
>9. Media type should not carry any semantics beyond "this is the format =
of
>the content of the message body"
I believe this statement to be true, but I don't understand this statement =
in this context. Does is argue for or against new methods or POST?
>10. We should preserve the ability to use different media types to do the
>same thing.
What does this statement mean? Does it mean we need to use different =
media types "application/postscript" and "application/pcl" (or whaterver =
the right media type is for PCL) to do the same thing, in this case =
identify the format of printer-ready data? Again, I believe this =
statement to be true, but I don't understand this statement in this =
context. Does is argue for or against new methods or POST?
>11. The existing Web framework is built around methods. If we are =
talking
>about extensions to HTTP/1.x, then you would expect those extensions to
>follow the framework of HTTP. If you care about the existing
>implementation base and the advantages provided by HTTP's generic
>interface, you will stay within the existing framework.
The IPP WG discussions between 12/96 and 5/97 stablized on the latter: "If =
you care about the existing implementation base and the advantages =
provided by HTTP's generic interface, you will stay within the existing =
framework." Discussion was held, decisions were made, and consensus was =
declared and it has stayed that way for the past 6 months. =20
It has been considered to many to be a "barrier to success" to "force" =
infrastructure development to support IPP when the same functionality =
could be realized with no dependency on new infrastructure. Some say =
supporting new methods on existing web servers is just as easy as =
supporing a POST, however, it is obvious that that is not the case across =
the board. One of the key goals of IPP was and is to be succsessful with =
with existing infrastructure so that the solutions could be deployed and =
accepted on its functionality with no barrier to success. To be perfectly =
honest, look at all the changes from HTTP/1.0 to HTTP/1.1 - those changes =
were due to implementation lessons and deployment on a wide scale. If we =
wait for IPP due to implementattion dependencies or adoption on a wide =
scale which is slow due to waiting for a developing infrastructure, we =
will never find out how to move IPP/1.0 to IPP/1.1 and beyond.
>12. Look at PEP and what it recommends for how to extend HTTP. Decide
>whether we think PEP will succeed.
This issue is why I think the conclusion to #2 above is flawed. In order =
to extend HTTP/1.1 there must be an extension mechanism. Period. Is it =
obviously clear to all EXACTLY how to extend HTTP/1.1 with no new =
development? Yes - by using POST.
A final note:
I believe that WebDAVs approach to using new methods is great for WebDAV =
since, from my observations, the implementors of WebDAV will be web server =
developers. The implementors of IPP are not necessarily web server =
developers. In short on the server side, I see almost 100% overlap =
between Web server (HTTP/1.1) developers and WebDAV developers and almost =
no overlap between IPP developers and web server developers (either =
accross companies or accross divisions within companies). So it makes =
sense to me to tie together WebDAV and HTTP but it doesn't make as much =
sense to me to tie IPP into HTTP with new methods.
Scott
************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121=20
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson@novell.com
web: http://www.novell.com
************************************************************