1. The 2nd bakeoff was a powerful demonstration of growing acceptance a=
nd
improved implementation - poising IPP as an eminent standard by any
definition of the word.
2. I think it is straightforward (process) that issues raised at the
bakeoff should be addressed prior to further advancement of the
specification. This may occupy a short or long period of time... it dep=
ends
on us.
3. Issues related to IPP scheme and TLS, while no less important in ter=
ms
of adoption by the standards society, become more academic as energy bu=
ilds
behind IPPv1. We should pursue these (mandated) topics less on merit or=
urgency but more on diligent technical feasibility and interoperatiblty=
.
Let's do our best to determine, understand and uphold the spirit of the=
se
requested functions in our next version.
4. When the issues have been adequately addressed it will be appropriat=
e to
recommend a new version of IPP. Just as we shouldn't rush into this... =
nor
should we drag our feet. I agree we should avoid "creeping
functionality".
Linkage between organizations (IETF/PWG) and periodic sympathy (or lack=
of)
in timing of events (PWG meetings/events vs. IETF meetings/deadlines) c=
an
result in some real jamming of the accelerator or the brake, depending =
on
our perception of conditions. (I would hate to be in the IPP Chairman=92=
s
position!). I think a calm review of the history of IPP , would affirm =
that
we're run our share of stop signs (even skidded into a few telephone
poles!)... but this hasn't changed the overall effectiveness of our
resulting solution... only made the ride a bit more exciting!
One area where I perceive urgency is in harmonizing with other standard=
s in
formation (like IFAX). Here, however, I would urge IFAX to sample the
energy behind IPPv1 and, again, work with us on the actual feasibility =
and
operational characteristics rather than focusing on agency approval as =
the
only valid benchmark of a standard. No one is suggesting we abandon the=
goal of our charter or shift into neutral. IFAX should be able to look =
up
the road and see us coming without someone waving a flag and the IETF
should (I think does) encourage the attempted "merging" of these evolvi=
ng
standards rather than suggesting that neither can make a move toward th=
e
other without being specifically directed to do so. (I don't think this=
is
the intent of the IETF... it is the way we sometimes behave based on ou=
r
interpretation of the IETF process).
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
=