Subject: Re: IPP> HTTP vs. HTTP-lite -Reply

From: Larry Masinter <[email-masked]>
Date: Mon, 6 Jan 1997 20:39:26 PST

I was hoping to avoid taking sides in the "HTTP vs. not-HTTP" debate,
and just help with the question of 

 "IF you wanted to use HTTP, how would you do it?"

Clearly, there are many advantages to starting with a clean RPC
instead of HTTP if all that counts is single protocol simplicity.

Why not elaborate the options a little better before continuing with
what otherwise promises to be an endless debate without much
resolution?

- What does printing with RPC look like?
- What does printing with HTTP look like?

What's common? How do they differ?

I think there are many more important things to get done than just the
transport: what's in a job description, how does one describe printer
capabilities, etc.

# In HTTP, is is possible for the client to send a job, the printer bogs down
# in printing it, it never responds, and the client times out or the HTTP
# server stack times out waiting for the CGI script to finish, and then
# resends the job and the job is printed twice?

Most RPCs don't have transactions either. It would be a bad idea for
HTTP-based printing to wait before returning from the POST that
submits a print job. I'd suggest
  a) HTTP POST to submit the job, return a URL for job status
  b) client polls job status URL to get state
This doesn't require connections or clients to stay alive. The job URL
should be unique. Having an active job have a unique URL has a lot of
advantages, e.g., 'cancel' can be an operation on the job URL, and it
scales nicely into print redirectors.

If you want to avoid duplicate print jobs, have HTTP post return a job
URL and require another "go ahead" operation to actually start
the job print. If the initial post fails, you don't get the
job URL. If you get the job URL and don't get an ack from the "go
ahead", you can try ack-ing again.

I think this works independent of whether you're using HTTP or some
other kind of RPC, but it maps nicely into the "URLs locate resource"
model of the web.

It may be that WEBDAV will require HTTP transactions anyway, though.

# It seems like caching and proxies is only an issue on GETs.

Actually, no. Other requests can be cached too. It's only if you leave
out cache control headers entirely that the method matters.

# As was pointed out in the BOF, most of the IPP operations will
# probably be MIME encoded requests in a PUT with the response coming
# back in the response to the PUT.

PUT is almost never appropriate for printing; try "POST" instead.

# However, I agree with Keith, that all of the work being done for
# HTTP/1.1 and beyond is NOT taking the needs of printing into account!

This is true about the past, but there's actually not much left for
HTTP/1.1 except for clarifications, fixing bugs, and a few odds and
ends, some of which seem also relevant to printing:

a) content and feature set negotiation
  (although printing and fax need the converse)
b) versioning & distributed authoring
  (transactions? updates?)
c) protocol extensions (PEP)

Regards,

Larry

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Jan 1997 02:00:55 -0500

>  "IF you wanted to use HTTP, how would you do it?"

I think we were both trying to address that question.

We differ about how we go about answering it.  For me, the questions are: 
how do I use HTTP without buying into all of the complexity of an HTTP 
implementation that's not needed for printing? and:  What's the minimum
core portion of HTTP that's useful as a generalized RPC mechanism?  I 
hate to burden an embedded system with lots of protocol baggage that's 
not needed.

The other difference is: I'm not willing to assume that the unneeded
features of HTTP won't cause problems... *especially* when people
threaten to use unmodified HTTP client libraries in their printer client
implementations.

> transport: what's in a job description, how does one describe printer

Absolutely.  IMHO, this is where the real work lies.  Solve these problems,
figure out the minimum command-set that does what's needed, figure out
how to avoid duplicated or lost print jobs in the event of race conditions,
client crashes, or server crashes... and any reasonable and simple rpc 
protocol (that can handle large payloads) will work just fine.

>   b) client polls job status URL to get state

Yep, I was about suggest something similar.   And yes, you'll have to
do this regardless of what rpc mechanism you use, but it will work
with any reasonable rpc mechanism.  I even think HTTP is a pretty 
good rpc mechanism to start with, because it's used to dealing
with large payloads, and -- with 1.1's chunked transfer-encoding -- 
doesn't require you to know the exact length of a file before transmission.
But *only* if we take out most of the cruft first.

> It may be that WEBDAV will require HTTP transactions anyway, though.

Perhaps, but let's not burden the print group with having to wait
on another group's output.  That can cause months or even years 
of delay.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Mon, 6 Jan 1997 22:40:30 PST

# how do I use HTTP without buying into all of the complexity of an HTTP 
# implementation that's not needed for printing? and:  What's the minimum
# core portion of HTTP that's useful as a generalized RPC mechanism?

Use a minimal HTTP/1.1 implementation.

Now I'll have to prove this, right? I think a minimal HTTP/1.1 server
can be implemented very simply; despite all of the MUST's in HTTP/1.1,
most of the additional "MUST" requirements are on proxies and not on
clients or servers, and even then, you can avoid most of the burden by
judicious use of cache-control headers.

I think there were too many 'MUST's in HTTP/1.1 proposed standard, and
I hope we can drop the unnecessary ones.

# I hate to burden an embedded system with lots of protocol baggage
# that's not needed.

I hate to burden HTTP with a lot of protocol baggage that's not needed
by those applications that don't need them.

# The other difference is: I'm not willing to assume that the unneeded
# features of HTTP won't cause problems... *especially* when people
# threaten to use unmodified HTTP client libraries in their printer client
# implementations.

I'm not willing to assume that we're stuck with features of HTTP that
aren't needed.

# Yep, I was about suggest something similar.   And yes, you'll have to
# do this regardless of what rpc mechanism you use, but it will work
# with any reasonable rpc mechanism.  I even think HTTP is a pretty 
# good rpc mechanism to start with, because it's used to dealing
# with large payloads, and -- with 1.1's chunked transfer-encoding -- 
# doesn't require you to know the exact length of a file before transmission.
# But *only* if we take out most of the cruft first.

Name two examples of cruft (ok, Host: and cache-control:), but name
two more examples of cruft.

# > It may be that WEBDAV will require HTTP transactions anyway, though.

# Perhaps, but let's not burden the print group with having to wait
# on another group's output.  That can cause months or even years 
# of delay.

Waiting? I was just suggesting that something that Internet printing
might not need right now (unless you're printing checks at remote
locations) was "along the path of development" of HTTP.

Besides, WEBDAV thinks they'll be done in 3 months ;)

Larry