Subject: IPP> FW: POST vs. New Methods

From: Josh Cohen <[email-masked]>
Date: Mon, 26 Jan 1998 16:21:15 -0800

An interesting datapoint about new methods
vs overloading POST.

-----Original Message-----
From: Judith Slein [mailto:[email-masked]] 
Sent: Wednesday, January 21, 1998 1:12 PM
To: [email-masked]
Subject: POST vs. New Methods

Larry Masinter suggested that I forward this information to the HTTP-NG
mailing list, feeling that it is relevant to discussions you have had
recently.  It's a summary of a discussion that occurred on the WebDAV
mailing list about 15 months ago, about the merits of extending HTTP with
new methods vs. relying on POST with new mime types.  WebDAV did start out
with a specification using POST, but decided to change its approach to
introduce new methods.

Issues raised on the WebDAV mailing list:

1. How do proxies / security gateways behave with POST with a new
entity-body vs. new methods?  Need to do a survey.

2. Separate methods are certain not to introduce new constraints on HTTP,
whereas using POST might do so.

3. Separate methods are cleaner for existing servers to deal with.  Using
POST might cause unpredictable results from existing servers. (a
controversial claim)

4. Using separate methods stays closer to the simple OO model of the Web,
where operations are defined on resources.

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-oriented
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).

6. Separate methods are simpler and cleaner for server vendors to
implement. (Some server implementors felt very strongly about this.)

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)

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"

10. We should preserve the ability to use different media types to do the
same thing.

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.

12. Look at PEP and what it recommends for how to extend HTTP.  Decide
whether we think PEP will succeed.

---

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 26 Jan 1998 23:34:06 -0700

>>> Josh Cohen <[email-masked]> 01/26 5:21 PM >>>

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.

>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.

>POST might cause unpredictable results from existing servers. (a

Again this claim seems backwards to me, note the controversial claim

>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.

>caches), and can be used to implement a simple access control scheme

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.

>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.

>it is to modify method definitions. (a controversial claim)

So, this argues for POST right?

>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

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?

>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.   

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.

>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 
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: [email-masked]
web: http://www.novell.com
************************************************************