All,
I sent this proposal for IPPEXT to the Application Area Directors almost
two weeks ago. I had hoped to have a response back from them by now, but as
I have not, I am now sharing this with the rest of the WG.
Something that will need resolution soon is whether the new IPPEXT WG will
be created before the next IETF meeting or if we will hold another BOF
session instead.
Carl-Uno
-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros at cp10.es.xerox.com]
Sent: Friday, January 14, 2000 2:03 PM
To: Moore, Keith; "Fältström, Patrik"
Cc: Manros, Carl-Uno
Subject: Proposed Charter for IPPEXT
Keith and Patrik,
I am eventually starting to catch up on various things that did not get done
last year due to vacation and flu (more flu than vacation actually).
I attach the proposed charter text for the IPPEXT WG as discussed in the
IETF47 IPPEXT BOF meeting.
There are a few points that I like your feedback on:
1) I kept the same DL, archive and web page names as for the earlier IPP WG
as this is a direct continuation of the earlier work. If you want me to set
up a new DL etc. I can still do that.
2) We have done initial work on new IPP operations in the old WG. I plan to
start over with new names and drafts, see charter, (referencing the older
I-Ds for anybody interested in history).
3) Similarly, we have several I-Ds out on IPP notifications. Also there I
plan to start over and give them more consistent names, see charter.
Notifications has been and will probably continue to be the hardest nut to
crack. There is considerable interest to use IM for the delivery of
notifications, but the IMPP work in the IETF is as you know still far from
becoming stable, so we currently have four other different delivery methods
on the table. One that uses SMTP email, one that uses SNMP traps, one that
extends the IPP protocol and makes it wait for portions of a multipart MIME
body to be delivered in pieces, and finally one that defines a new
independent delivery protocol over HTTP. Each of these has it's pros and
cons and they offer different functionality in partly different scenarios.
We hope to end up with one or two delivery methods as required if you do IPP
notifications in the first place, and possibly leave the remaining ones as
Informational. Have you got any views on that?
4) Do you think that we will have the new IPPEXT charter in place for
IETF47, or should I rather go for a second BOF in the IETF47 meeting?
Independent of this charter, the IEEE-ISTO PWG is planning to start up
additional work on special IPP extensions like production printing and color
functionality later this year, as discussed in the IPPEXT BOF meeting. That
work will be done over a separate PWG DL, but as before, that PWG list will
be open to anybody with an interest to participate. I expect that the PWG
will offer to share the outcome of that work with the IETF, perhaps to be
published as Informational RFCs, if the IESG so chooses.
The general mind share for IPP keeps increasing and several new IPP products
will hit the market in Q1.
Getting Microsoft's Windows 2000 out the door will obviously help, as it
will give every Win 2000
desktop a built-in IPP client. I am also eagerly waiting for the next MacOS
X version, which is rumored
to have a much more full featured IPP client than that in Win 2000.
Regards,
Carl-Uno
Carl-Uno Manros
Principal Engineer - Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
-------------- next part --------------
Proposed Charter:
================
IPPEXT - Internet Printing Protocol Extensions
Chair(s): Carl-Uno Manros <manros at cp10.es.xerox.com>
Application Area Directors:
Keith Moore <moore+iesg at cs.utk.edu>
Patrik Faltstrom <paf at swip.net>
Area Advisor:
TBD
Mailing list:
General Discussion: ipp at pwg.org (would be easier keep the existing one)
To subscribe:
majordomo at pwg.org
Subject line should be blank
In body: subscribe ipp [your e-mail address]
Archieve: <http://www.pwg.org/hypermail/ipp>
Web pages: <http:// www.pwg.org/ipp
Description of Working Group:
The original IPP Working Group was chartered in 1997 and made the first deliverables
in 1999, when the IPP/1.0 version was published in April as RFCs 2565-2569, labeled
as Experimental, followed by an Implementer's Guide RFC 2639 in July 1999. The IPP
WG also submitted a set of IPP/1.1 Internet-Drafts intended for the IETF Standards
Track in 1999 for IESG review and RFC publication. With that the original charter
from 1997 was deemed to be complete. Intial work has also been started on additional
IPP functionality, which purposely was left out from the original, IPP charter. This
new IPPEXT charter addresses two main areas that were earlier postponed.
- The first area has to do with additional functionality mainly needed by administrators
and operators of a printer, rather than end users, which was the scope for the IPP WG.
- The second area has to do with printer initiated notifications back to end-users,
operators or administators.
Problem Statement:
=================
Although the initial set of operations in the IPP protocol well serves to provide the
common functionality needed by most end users, it still lacks features needed by
administrators to initially configure printers (unless they accept all "out-of-the-box"
default settings) or to change them later. There are also features lacking for
operators, often present with bigger shared printers or print servers, to control
the printer over the IPP protocol. Certain of these operations will need to be
directed to the logical "IPP printer", while others need to impact the actual printer
device.
The currently defined functionality in the IPP protocol allows for an IPP to poll the
IPP printer with regular interwalls to find out the status of a submitted print job,
like email clients typically check for mail over POP3 or IMAP4. However, there
have been requests to also add a notification feature, which would send a message
to an end user, or operator, triggered by events in the IPP Printer, like job finished
or printer ran out of paper or needs toner etc.
Work Group Objectives:
=====================
To address the two areas described above and produce compatible extensions to the
current IPP protocol to provide the additional functionality. The old IPP WG has
already done initial work in both of these areas and it is felt that the work at
hand is well understood, but not neccesarily trivial to resolve.
The IPPEXT WG will continue to closely coordinate its activities with other WGs in
the IETF, in particular on subjects related to:
- HTTP
- Security
- AAA
- IMPP
- FAX
- CONNEG
- QUALDOCS
Goals and Milestones:
====================
For Additional IPP Operations:
-----------------------------
IPP/1.1: Job and Printer Set Operations - WG Last Call March 2000
<draft-ietf-ippext-job-printer-set-ops-xx>
IPP/1.1: Job and Printer Adminstrative Operations - WG Last Call June 2000
<draft-ietf-ippext-job-printer-admin-ops-xx>
IPP/1.1: Device Administrative Operations - WG Last Call June 2000
<draft-ietf-ippext-device-admin-ops-xx>
For IPP Notifications:
---------------------
IPP/1.1: Requirements for IPP Notifications - WG Last Call September 2000
<draft-ietf-ippext-not-requirements-xx>
IPP/1.1: IPP Event Notification Specification - WG Last Call September 2000
<draft-ietf-ippext-not-spec-xx.doc>
IPP/1.1: The 'ipp-smtp' Notification Delivery Method - WG Last Call September 2000
<draft-ietf-ippext-not-smtp-delivery-xx.txt>
IPP/1.1: The 'ipp-snmp' Notification Delivery Method - WG Last Call September 2000
<draft-ietf-ippext-not-snmp-delivery-xx.txt>
IPP/1.1: The 'ipp-get' Notification Delivery Method - WG Last Call September 2000
<draft-ietf-ippext-not-get-delivery-xx.txt>
IPP/1.1: The 'ipp-ntfy' Notification Delivery Method - WG Last Call September 2000
and Protocol
<draft-ietf-ippext-not-ntfy-delivery-xx.txt>