ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0198.txt
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0198.pdf
**********************************************
* Don Wright don@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
-----------------------------------------------------------------
Internet Printing Project Meeting Minutes
January 28/29, 1998
Kaanapali, Maui, Hawaii
The meeting started on January 28, 1998 at 10:30 AM led by Carl-Uno Manros.
These minutes were recorded by Don Wright. The attendees were:
- Randy Turner - Sharp
- Ron Bergman - DataProducts
- Peter Zehler - Xerox
- Lee Farrell - Canon
- Bob Pentecost - HP
- Dave Kuntz - HP
- Kris Schoff - HP
- Don Wright - Lexmark
- Tom Hastings - Xerox
- Carl-Uno Manros - Xerox
- Stuart Rowley - Kyocera
- Bob Herriot - Sun
- Henrik Holst - I-Data
- Atsushi Uchino - Seiko-Epson
- Xavier Riley - Xerox
- Harry Lewis - IBM
- Josh Cohen - Microsoft
- Paul Moore - Microsoft
- Jim Walker - Dazel
- Roberto Sannino - SGS Thomason
Conference Call Dial-in Participants:
- Jay Martin - Underscore
- Ira MacDonald - HighNorth
- Scott Isaacson - Novell
- Roger Debry - IBM
- Keith Carter - IBM
- Steve Gebbler - IBM
- Carl Kugler - IBM
- Sven Johnson - Xerox
- Peter Michalek - Shinesoft System
- Daniel Manchala - Xerox
- Shivaun Albright - HP
Carl-Uno Manros reviewed the agenda for the day.
Paul Moore started off the meeting with an overview of the Microsoft XML
proposal including the proposal to use another method rather than POST.
The
charts used were distributed on the mailing list as IPPPRES.PPT,
IPPPRES.PDF and
as text before the meeting.
The first area of discussion was whether we should use the POST method or
create
new methods. John Cohen presented the results of an informal survey he
conducted asking HTTP server and Firewall vendors what they thought about
it.
He reported that most of those he surveyed did not what to overload POST.
Next, Paul Moore presented the reasoning behind proposing XML as the
structured
data representation rather than the current IPP proposal. XML offers a way
of
describing complex structured data that wasn't available when the group
originally considered using an simple ASCII representation.
The proposal includes including the DTD in the spec but not forcing
run-time DTD
checking. Additionally XSL would not initially be included. Paul and Josh
suggest using weak typing using multi-part related MIME.
When should we do this?
- with IPP V1
* XML is not ready yet
* Creates legacy
- with IPP V2
- Never
Paul and Josh recommend doing it now using a simple subset of the total XML
definition.
Paul Moore listed the benefits of going to XML:
1) Extensibility issues which we haven't hit are probably already addressed
by XML.
2) 3rd party tools that know how to parse XML will be able to parse IPP.
3) In environments where XML already exists, less new code is needed.
The group identified some disadvantages of XML:
1) Over the wire, XML is less byte efficient than existing IPP.
2) Implementation experience would indicate that an XML parser would take
2 to 3 times more code space.
The group broke for lunch.
After lunch, the conference call began.
The first issue discussed was whether we should discuss the technical
merits of
the proposal or discuss its appropriateness first. The group voted as to
whether to discuss the technical merits or to reject the proposal as "too
late"
(Yes = Discuss, No = Reject)
No Votes 13: Jay Martin, Ira MacDonald, Scott Isaacson, Roger Debry, Keith
Carter, Steve Gebert, Carl Kugler, Sven Johnson, Peter M. (Shinesoft
System),
Daniel M. (Xerox), Ron Bergman, Harry Lewis, Don Wright
Yes Votes 16: Randy Turner, Bob Pentecost, Kris Schoff, Dave Kuntz, Stuart
Rowley, Henrik Holst, Paul Moore, Josh Cohen, Asushi Uchino, Lee Farrell,
Jim
Walker, Bob Herriot, Xavier Riley, Peter Zehler, Tom Hastings, Carl-Uno
Manros
The group began discussing the issue of replacing the POST method with one
or
more IPP specific methods. Paul Moore presented a summary of this issue
for the
conference call participants. There were are number of arguments presented
from
the other side including changes needed for many web servers, the fact that
others use POST to pass data to back-end applications, etc.
Roger Debry questioned the capability of adding additional methods to
servers
and hooking those methods to a Java Serverlet.
The group discussed whether having a separate method would assist firewall
administrators in differentiating print function versus using other ways to
different and deal with the security issues of POST.
Once the proposal goes to the IESG, there is a real possibility that the
issue
of POST could be raised as well as almost any other thing including the
perpetual question of "why are we using HTTP?"
No decision was made on this issue. The group moved to the issue of XML.
Paul
Moore presented the summary of "why XML" again.
Bob Herriot presented his views on the PROs and CONs of using XML.
The group discussed the issues again including data typing, new data types,
footprint size of XML parser, etc. There were widely divergent opinions
expressed.
A discussion on the overall merits of XML and the problems with delaying
IPP due
to time to market issues. If we delay will some now non-compliant internet
printing products ship confusing the marketplace?
Randy Turner proposed forwarding the document to the IESG for last call to
prevent the group spending 3 to 6 month on XML and then having the IESG
reject
the XML proposal.
Should we send the current documents with the binary protocol to the IESG
for
last call?
Submit Now: Roger Debry, Carl Kugler, Steve Gebert, Keith Carter, Harry
Lewis,
Ron Bergman, Jay Martin, Ira MacDonald, Shivaun Albright, Daniel M., Stuart
Rowley, Henrik Holst, Atsushi Uchino, Don Wright, Bob Herriot, Xavier
Riley,
Peter Zehler, Tom Hastings, Carl-Uno Manros, Randy Turner
Wait later: Bob Pentacost, Kris Schoff, Dave Kuntz, Paul Moore, Josh Cohen,
Jim
Walker
The group re-affirmed its desire to take the existing documents to last
call.
The group began discussing what should be discussed tomorrow; some of wich
could
be considered for future enhancements for IPP V1+:
- Enhancements in the area of multiple documents
per job
- document object
- attributes for that object
- Have we tried to please too many masters by
developing a protocol for both the embedded printer
and server based solutions?
- Should we add a higher level of abstraction above
"printer" to be able to represent a server with a
pool of printers attached.
- Revisit the philosophical decision to limit the
intersection of IPP and SNMP. Should all the SNMP
information be available through the IPP?
- Automatic IPP printer installation
- Notifications
- Authorization (Access Control Lists)
- Job Management
- Printer Management
- Print System Management
- IPP MIB
- Printing Commerce
- Accounting
- Fonts
- Dictionary Syntax
- Universal Print Driver Overview
The meeting adjourned for the day at 5:15 PM.
The meeting resumed on Thursday at 8:45 AM.
Peter Zehler led the discussion on the Testing and Prototyping effort. The
agenda was:
A) Testing methodology
1) How to test an implementation
- test suite
- scenarios
- simple instructions, capture of results, compare
- trace file repository
2) Internet Pair-wise test/bake-off
3) Face to face bake-up
4) How to document results
5) Establish milestones
- develop test plan (Pete & Randy) 2 weeks
- organize pair-wise testing (Pete)
- update FAQ (Carl-Uno) 2 weeks
6) Public Demo
- At a trade show such as Xplor or Fall
Networld-Interop
- At some other locale
B) Conformance/Compliance
1) Minimum level definition
2) Operation & Attribute coverage
3) Security coverage & intervention
C) Preliminary Schedule for milestones, action items and deliverables
- Who is developing IPP clients/servers?
IBM (prototype client ready, server not ready)
Sharp (prototype server ready, client almost)
-- ipp.sharplabs.com
HP (defers to Microsoft (client and server))
Kyocera (not ready)
I-Data (not ready)
Microsoft (client and server prototypes subsequent to
NT Beta 1)
Epson (not ready)
Canon (not ready)
Dazel (not ready)
Lexmark (not ready)
Sun (not ready)
Xerox (1 test client, 2 servers)
- How soon can pair-wise testing occur?
- Develop test plan (Pete & Randy)
- test cases
- good
- bad
- chunked
- collect and document problems, post to
TES DL (Pete Z)
- Hide owners of prototype in test
- less of concern with early prototypes versus
shipping products
- advantage of privacy from 3rd party
- disadvantage in follow-up
- should focus on misunderstandings of the spec
- data gathered could be used to create an
"Implementers guide to IPP"
What do we think the behavior be if the client is unable to send a job to a
non-
spooling printer?
- should operations, etc. be defined in the protocol
to handle this?
- should the client report back the situation
but continue trying but send without "locking
out" the user?
- is this a TCP/IP, an HTTP, or an IPP error?
- How do we make IPP a great experience?
- How can IPP be able to do much more than what LPD
and other existing print services?
- Can we come up with a consistent contention model
due to the interaction of IPP with Web
servers, etc.
- Contention is not an error, it is really
normal operation.
- Should we more accurately call some of the
responses as status codes rather than error codes?
- Randy will post a list of network programming
issues for IPP. A subgroup will be formed from
interested parties after this is posted. Paul
Moore and Randy Turner will kick off this effort
to clarify the contention behavior of V1 and
identify potential work in this area for a future
enhancement to IPP V1. The LP-to-IPP mapping
document should include this issue.
The group attempted to identify the high priority items from the discussion
list
created yesterday.
6 - Enhancements in the area of multiple documents
per job
- document object
- attributes for that object
0 - Have we tried to please too many masters by
developing a protocol for both the embedded
printer and server based solutions?
2 - Should we add a higher level of abstraction above
"printer" to be able to represent a server with a
pool of printers attached.
10 - Revisit the philosophical decision to limit the
intersection of IPP and SNMP. Should all the
SNMP information be available through the IPP?
2 - Automatic IPP printer installation
6 - Notifications
0 - Authorization (Access Control Lists)
6 - Job Management
6 - Printer Management
1 - Print System Management
0 - IPP MIB
1 - Printing Commerce
3 - Accounting
5 - Fonts
1 - Dictionary Syntax
9 - Universal Print Driver Overview
1 - defaulting
Dictionary Syntax: Tom Hastings and Roger Debry will present a proposal.
IPP versus SNMP:
- server based versus embedded
- if we add a "server" to the model, on which end
of the protocol is the server?
+ from the printer perspective the server is on
the source end
+ from the client perspective the server is on
the target end
- IPP Method to retrieve SNMP OID?
- Could additional printer attributes to enable
getting and setting printer characteristics that
are now only accessible by using SNMP.
- What would the media model be -- select by tray
or select by name?
-- the OS probably needs both because the
user might want to see it presented
different ways.
- Could use IPP to configure drivers?
- We could push to get SNMP mgmt of printers allowed
through firewalls
- Tom Hastings will kick off the efforts. Interested
participants should contact Tom.
Universal Printer Driver:
Paul Moore described the capabilities of GPD and Unidrive 5 from the
perspective
of creating a universal print driver.
+--------------------+
| |
| Client |
| |
+--------------------+
^
|
V
+--------------------+
| |
| Unidrive 5 |
| |
+--------------------+
^ |
Generic | | +-------+
Printer ------- +---->| |
Description | Prtr |
+-------+
The OS uses the GPD to dynamically build the UI for the printer based upon
the
device options, constraints and other information provided with the printer
and
information provided at install time. The GPD syntax has the ability to
include
macros which can be called to set a group of setting to achieve some
singular
purpose (fastest, best quality, etc.)
GPDs
- ASCII text
- about 30K per printer
- escapes for advanced features / UI
- NT 5 supports about 1000 printers
Documentation for GPD is available in the NT 5 DDK.
Paul Moore proposed that the group look at the current GPD syntax and
investigate standardizing the syntax. There are certain parts of GPD today
that
are Windows specific and would perhaps need to be made more general.
Additionally, additional functions could be identified that might need to
be
added.
The group decided to take a look at specification and whether to work on
this as
a standard will be discussed at a future meeting.
Notification:
Randy Turner presented his thoughts on notification. . .
- Should it be ASYNC (out of band)?
- How timely should the notification occur?
- Should it be reliable
- Should we use a protocol outside IPP?
- What type of information should be included in a
notification? (Enumerate type of notifications)
- Subscription and filtering
- Subscription lifetimes
** Are "job finished" kind of messages which might be
e-mailed different from other types of notifications
(i.e. alerts( such as "interpreter error"
** Should the "alert" contain both machine readable and
human readable fields
** Should notifications be directly readable by the
recipient or should an application that receives the
notifications be assumed?
** E-mail is really a special case that should be optional
and included with the job submission that creates an
e-mail when the job completes, aborts, etc.
** Could have both e-mail and IPP protocol notifications
where the IPP protocol notification reports a
superset of the e-mail method.
** LDAP includes something called a "persistence search"
which includes maintaining an open connection which
causes the notification to return when the criteria is
met. We could use a similar concept.
** If we specified a means where the printer would notify
by opening a connection on a certain port then that
would require the client to listen for opens.
** Should we look at SENSE again? How is it applicable to
this scenario? There are a number of issues about
opening and maintaining connections. How does the
server remember subscriptions if the connection is
closed? John Cohen says there are some other efforts
underway to create a generic notification service.
He will post more information on the mailing list.
Job Management:
- Additional job management operations like
* Hold, Resume
* Move
* Modify
Printer Management:
- Is SNMP good enough?
- What about its reliability? What about firewalls
and SNMP?
Multi-document Jobs:
- Need to add the Document Object back into the model
- Would allow more flexibility to controlling documents
- Jim Walker will distribute his thoughts on this
subject to the DL.
Do we need a slot in the next IETF meeting? -- Yes.
The meeting adjourned at 5:35 PM.