IPP> Some notes from an IETF Area Director

IPP> Some notes from an IETF Area Director

IPP> Some notes from an IETF Area Director

Harald.T.Alvestrand at uninett.no Harald.T.Alvestrand at uninett.no
Fri Jan 3 09:28:50 EST 1997


Hi,
I thought it ought to be time for me to butt in on your discussions.


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



More information about the Ipp mailing list