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.


Your statement is a tautology: "tunnelling through POST" prevents you from
"not tunnelling through POST".

The question was about using POST uniformly vs. using PRINT uniformly,
I thought. There's been no discussion of mapping IPP into a variety of
*different* methods. If that's what you have in mind, it's a significant amount
of additional work. "One is constantly forced to re-invent features", you say,
but the invention has been done, tested, and through Last Call. Maybe it
is a shame they had to invent all of that stuff, but, now that they have, what's
left?


>For example, IPP does not use URLs to refer to print jobs.

Yes, I agree, this is the main problem.

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

Exactly, but the question is no longer "POST" vs "PRINT" but rather
"this architecture" vs "a different architecture that hasn't been invented yet"

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

But OPTIONS is really more general; the question isn't 'which options do
you support', but something much more specific.


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


You want to treat a print spool as a DAV collection? Probably you'll need
more than ordered collections.


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


We're not talking in the abstract, though, we're talking about the current specific
concrete proposal to use POST vs another specific concrete proposal to use
PRINT but keep all of the rest of IPP alone. In that comparison, there is _no_
advantage to using PRINT over POST.

Received on Saturday, 28 February 1998 21:14:59 UTC