The most important is that it still aims to provide the "big service"
with bells, whistles and kitchen sink instead of the "little service"
that can be supported easily and will work under most circumstances.
My comments are inserted using *** below.
Happy drafting!
Harald A
(DRAFT 12/23/96)
IETF Internet Printing Protocol (ipp) WG
Chair(s):
Carl-Uno Manros <manros@cp10.es.xerox.com>
*** Seriously consider increading the size of the management team.
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Area Advisor:
TBD
Mailing List Information:
General Discussion: <ipp@pwg.org>
To Subscribe: <ipp-request@pwg.org>
Archive: ftp://ftp.pwg.org/pub/pwg/ipp/
Editors:
Scott Isaacson <scott_isaacson@novell.com>
Robert Herriot <robert.herriot@eng.sun.com>
Don Wright <don@lexmark.com>
Description of Working Group:
*** Spend a few sentences on WHY this work is needed.
The goal of this working group is to define a new application level
distributed printing protocol as well as defining naming and service
registration attributes for printing. The protocol shall support a
global, distributed environment where print service users (clients,
applications, drivers, etc.) cooperate and interact with print service
providers (servers, printers, gateways, etc.).
*** Please use separate sections for the core (protocol) and the
*** additional features (naming and service registration).
The working group will leverage existing (and emerging) technologies
for: authentication, authorization, privacy, and commercial transactions.
The working group will describe a generic directory schema that supports
printing, which can be mapped to existing standards for directories.
*** It is not clear from the text WHY you need to do this.
*** If you need commercial transactions, earlier text must explain why.
*** Some words on requirements for auth&auth are needed, too.
The working group shall strive to coordinate its activities with other
printing-related standards bodies.
*** Name the bodies.
The new job submission protocol should strive not to preclude any
types of output devices (e.g., fax, printer, gateway). Also, the
working group will define extensibility paths to maximize interoperability
and minimize conflict.
*** Delete this paragraph. It's an opening for a rathole.
*** I would be MORE happy with a list of explicitly PRECLUDED devices.
The latest IETF requirements for management, security, and inter-
nationalization shall be covered.
*** This paragraph is not needed. YOU need to consider management
*** et al; you have to define what you need.
Deliverables and Milestones:
Done - Mailing list and archive
November 1996 - Submit first set of Internet-Drafts
December 1996 - BOF in IETF meeting in San Jose, CA, USA
March 1997 - Submit Internet-Drafts
April 1997 - Review of specification in IETF meeting in Memphis, TN, USA
May 1997 - At least 2 implemented prototypes
May 1997 - Submit document(s) to the IESG for Proposed Standard
Current Internet-Drafts:
IPP-requirements: <draft-wright-ipp-req-01-txt>
IPP-draft: <draft-isaacson-ipp-inf0-00.txt>
Planned RFCs:
Internet Printing Protocol: Requirements and Scenarios (Informational)
Internet Printing Protoco/1.0: Model and Semantics (Standards Track)
Internet Printing Protoco/1.0: MIME Encoding (Standards Track)
Internet Printing Protoco/1.0: Directory Schema (Standards Track)
*** This list of RFCs is not well reflected in your charter text above.
*** In particular, requirements, scenarios, model and semantics are
*** VERY important; the charter does not mention that you will develop
*** them until this point.
*** None of the RFC titles here sound like a protocol spec.