RE: draft-cohen-http-ext-postal-00.txt

One of the many problems with tunneling functionality through POST is that
it prevents one from leveraging HTTP. Rather one is constantly forced to
re-invent features.

For example, IPP does not use URLs to refer to print jobs. Thus rather than
using the DELETE method to remove an unwanted print job one is forced to
re-create the DELETE method's functionality inside of IPP's POST protocol,
which is exactly what they have done. Additionally when discovering support
for various features in IPP rather than using OPTIONS, IPP creates its own
feature discovery mechanism by, once again, tunneling through POST.

In the future should one, for example, want to be able to move a spooled
print job from one printer to another, a simple feature for an IPP
compatible print spooler, instead of leveraging the specifications and
software already written in the DAV effort one will, once again, have to
extend the POST format.

Anyway you look at it, security, performance, extensibility, or
interoperability, tunneling through POST is a bad idea.

			Yaron

> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Friday, February 27, 1998 4:55 PM
> To:	Josh Cohen; koen@win.tue.nl; ietf-http-ext@w3.org
> Cc:	rdebry@us.ibm.com
> Subject:	Re: draft-cohen-http-ext-postal-00.txt
> 
> For what it's worth, my opinion on POSTal:
> 
> Whether an operation deserves a new method depends on whether the
> operation
> is likely to be applied to the same resource that ALSO might respond to
> GET,
> POST, or PUT. Otherwise, you're better off using an existing method with a
> different
> URI or content-type or modified headers.
> 
> In the case of WebDAV, the protocol is adding new operations to existing
> resources.
> In the case of IPP, the protocol is actually just being applied to new
> resources ("printers").
> 
> So WebDAV needs new methods, but IPP can use POST without a problem.
> 
> The "firewall" issue is a red herring. (Yes, it's red. No, it's
> irrelevant.)
> 
> Larry
> 
> 
>

Received on Friday, 27 February 1998 20:15:01 UTC