Bill Wagner first brought this topic (IPP/2.0) up during a recent WIMS-CIM
WG teleconference, when he observed that many or most implementors
of IPP are not aware of the large suite of extensions, some of very high
importance for their added functionality. An IETF standards-track IPP/2.0
Technical Specification would greatly improve the visibility of more recent
PWG extensions to IPP.
At today's PWG Steering Committee teleconference, I briefly described a
possible approach for writing a *very* brief IETF standards-track RFC that
would define "IPP/2.0" by including REQUIRED, RECOMMENDED, and
OPTIONAL references to the entire suite of both IETF standards-track and
PWG standards-track specifications that have been published in the 7 years
since IPP/1.1 (RFC 2910/2911, September 2000).
The approach I recommend is the one followed by the IETF LDAP WG.
See the *395* line IETF LDAPv3 Technical Specification (RFC4510) at:
An IPP/2.0 spec might be a bit longer, because we might want to enumerate
important features of particular IETF or PWG specs (such as the Media object
or the Document object), with more fine-grained requirements.
An IPP Printer implementation that supported version "2.0" would have a
much wider set of capabilities than the original version "1.1".
(1) The PWG Steering Committee and membership should consider this
proposed approach and concur on approval to proceed.
(2) At least two editors should volunteer to write this IPP/2.0 TS as an
Individual Contribution to the IETF.
NOTE: Renewing the charter of the IETF IPP WG, although possible,
would be a heavyweight approach.
(3) The PWG Steering Committee should search for PWG members who
would be willing to prototype IPP/2.0.
(4) The PWG Steering Committee should approach the current IETF
Applications Area Directors about this approach.
(5) If the IETF Application ADs agree, then we should proceed. If the IETF
Application ADs do NOT agree, then the PWG might instead publish IPP/2.0
as an IEEE-ISTO PWG standard.
HOWEVER - a PWG standard will greatly reduce the visibility of these IPP
extensions to the wider network product community (i.e., firewalls, routers,
application gateways, etc.).
(6) An IPP/2.0 bakeoff should be scheduled and a report prepared for
submission to the IETF Application ADs, along with our IETF "last call
ready" Internet-Draft of the IPP/2.0 TS.
(7) The IETF standards-track process should then be followed in order
to achieve the goal of a new Proposed Standard RFC.
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
email: blueroofmusic at gmail.com