Subject: IPP charter

From: "Scott A. Isaacson" <[email-masked]>
Date: Mon, 11 Nov 1996 13:22:21 -0700

At the New Orleans meeting I presented a paper copy of
a proposed charter for the Internet Printing Project.  This was reviewed
on Thursday afternoon.  Thursday evening we came up with a new
version that I labeled 2.0.  Then the next day on Friday, we made some
additional changes, I am calling that version 3.0.

I have posted all three versions on the ftp.pwg.org server:

ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter1.(ps, pdf, txt)
ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter2.(ps, pdf, txt)
ftp://ftp.pwg.org/pub/pwg/ipp/charter/charter3.(ps, pdf, txt)

Version 3.0 is still not in a good final form.  It is just a cleaned-up
brainstorming list.  I hope to work on it in the next few days.  I am still
open to any suggestions or comments.

There was some discussion about what format or style the charter
should be in.  I believe that this is the exact format for sending the the
IETF area directors, and I plan to use this same exact document as a
charter for the working group (both informally now as we have
organized ourselves, and formally under the IETF).

************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: [email-masked]
W: http://www.novell.com
************************************************************

I have included the text below for reference:
---------------------------------------------------------------------
Charter 3.0
11/8/96

Internet Printing Project (ipp)
-------------------------------
 
 Chair(s):
     Carl-Uno Manros <[email-masked]>
 
 Applications Area Director(s): 
     Keith Moore  <[email-masked]>
     Harald Alvestrand  <[email-masked]>
 
 Area Advisor:

 Mailing lists: 
     General Discussion:  [email-masked]
     To Subscribe:        [email-masked]
     Archive:             ftp://ftp.pwg.org/pub/pwg/ipp

 Editor
     Scott Isaacson <[email-masked]>
 
Description of Working Group:

This working group will work to solve the following Internet printing
problems.  All solutions must be platform independent for maximum
effectiveness and deployment.

Locate and select via a browser
	- Name
	- Geographic Location
	- other attributes
	- control the scope and or context of searching

	NOTE: The use of the term Browser is specifically limited to an
Internet Web Browser (html, http, Netscape, Internet Explorer, Mosaic,
etc.).  It does not indicate MIB browsers or other browsers specific to a
proprietary product or technology.

Install this printer into the native OS 
	- including any printer driver or other support

Print:
	- from any desktop application (spreadsheets, word processors,
browsers)
	- print by reference
	- inside and outside firewalls
	- specifying submission attributes at submission time
	- design for programmatic printing

User query of via browser
	- status and capabilities
	- printer: number of  jobs, position of jobs, status of printer
	- job: status of job 

User selection of receiving events or not
	- job completed, job affectin printer status change, job status
change
	- own jobs only?  jobs affecting this job?
	- How are events delivered (e-mail, static html pages, live pages)
Solution must be platform independent

Capability matching
	- reject if printer can't print the job
	- find the right printer based on job attributes

Cancel Job
	- Your own job

Simple enough for embedding in a network attached printer
	- A legitimate implementation of this might be able to accept only
one

Objects
	- Printer
	- Jobs
	- Documents
 
Use but don't invent:

	Need an authentication mechanism
		- Prove you are who you are

	Need an authorization mechanism
		- Assign a role to the authorized entity
			V1 = Users
			V2 = Operators/Administrator

	Support for electronic commercial transactions (provide for or
use existing mechanism)
		- Payment along with job request
		- Negotiate the transaction, then get a authorization id back

Don't preclude

	Whatever we do should not preclude the notion of Logical
Printers
		- Allow for fun configurations
		- Protocol should allow for reporting where the job went
(if it was a Logical Printer)

	Whatever we do should not preclude output devices (fax, printer,
repository)

	Design goals for extensibility:
		- We need a path for similar extensions to interoperate
		- We need a way for proprietary extensions to never
conflict

Keep in mind:
	
	Give away the client side!
	Win hearts and minds
		- Browsers
		- Client OSs
		- NOSs
		- ISPs
		- PDLs
		- Service buereaus
	Lightweight enough that we can do it in 6 months.

Version 2 Suggestions

	Modify Job	Resubmit Job
		- similar printer (no need to change PDL)
		- dissimilar level (transform PDL as needed)

	Simple Operator/Management Commands (possibly V1)
		- Enable Printer
		- Disable Printer
		- Pause Printer
		- Resume Printer
		- Manage Roles
		- Create a Printer
		- Create and manage template
		- Cancel any/all jobs

	Job streaming support (open, write, ..., close)

What Internet Printing is NOT:
	How native OSs *temporarily* install printers
	Expose HOW this works to the user
	Don't care about marsahlling, PDLs, etc.
	No command line
	Not worry about how to print nested HTML docs (W3C)
	Not include  about Input devices (scan, fax-in)

Goals and Milestones:

	Weekly teleconference.  Wednesday

 Internet-Drafts:

   No Current Internet-Drafts.

 Request For Comments:

  RFC  Stat Published    Title 
------- -- ---------- -----------------------------------------
RFC1759 PS   Mar 95     Printer MIB