I've scanned most of your December archive, and think that I can give
you some feedback.
- First of all, we share one common goal: Making sure that we have
a well defined, workable, useful printing protocol.
IETF bureaucracy, advice about protocol choice and so on are *only*
tools to achieve that, nothing more.
- The reasons why many of us felt that HTTP is a poor choice for printer
operations are two:
- HTTP is a badly designed protocol.
HTTP/1.0 is ill-defined, unreliable and network unfriendly.
HTTP/1.1 is a lot better, but has to lean over backwards to be
backwards compatible.
- Lots of things in the world do special things with HTTP, like caching,
proxying and so on (the "baggage"). If you do printing through HTTP,
all those things will happen to printing too, whether they make
sense or not.
Our experience wrt the firewall argument is that lying to your security
staff is unwise - if printing is to be allowed through a firewall, it
can be turned on; if it is not to be allowed, the security staff will
get you no matter how you hide it sooner or later.
Making life easy for a firewall is a *feature*, not a bug.
- The LDAP effort is fully supported by the IESG.
We have doubts about it, as we have about many things including
multicast, RSVP and IPv6, and we know there are problems.
However, it is the alternative that we have at the moment, and one
that has proven that it is useful at least under some circumstances.
That's enthusiasm, seen from the IESG.
- On MIME and the length field: THe content-length in an HTTP header
is the length of the ENTIRE reply to an HTTP request. If the reply
is multipart, the content-length is the whole thing.
You would have to define application/ipp-style-multipart to get away
from the boundaries.
Note that the *important* part of MIME for you is the typing mechanism; in
particular, you shouldn't expect to have to do content-transfer-encoding
unless you send requests over E-mail.
- On drivers and All That: the requirement for something to be referred
to by a mandatory part of an IETF standard is roughly that it's documented
publicly (published book, standard or RFC). When there is any alternative,
we tend to prefer non-patented, non-proprietary specifications.
So if you want to mandate downloadable drivers, you might have to
specify that they are written in C or Java!
But again - our experience is that simple things get deployed; complex
things get forgotten; if you can specify an exchange that works
something like:
Are you a printer? -->
<-- Yes
Can you print PostScript? -->
<-- Yes
Print this! -->
<-- OK, I will
How is it going? -->
<-- Wait a bit
How is it going? -->
<-- Finished!
and can be implemented in 30 lines of Perl, either side, then you have
something that can be expected to become ubiquitous.
All the bells and whistles can come later, if you just leave yourselves
room in the right places, but START SIMPLE!!!!!!!!!!
Harald A