IPP Mail Archive: IPP> April 3rd Meeting Minutes

IPP> April 3rd Meeting Minutes

Don Wright (don@lexmark.com)
4 Apr 97 12:10:12 EST

Attached are the meeting minutes for the April 3rd meeting
of the IPP Working Group in Austin. In addition, I have
uploaded the .TXT and .PDF version on the ftp server as

ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0497.txt
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-0497.pdf

------------------------------------

Internet Printing Project Meeting Minutes
April 3, 1997
Austin, Texas

The meeting started on April 3rd, 1997 at 8:40AM led by Carl-Uno Manro. The
attendees were:

Ron Bergman - Data Products
Lee Farrell - Canon
Don Wright - Lexmark
Scott Isaacson - Novell
Jeff Copeland - QMS
Bob Pentecost - HP
Dave Kuntz - HP
Tom Hastings - Xerox
Harry Lewis - IBM
Roger Debry - IBM
William Wagner - Digital Products
Robert Herriot - Sun
Carl-Uno Manros - Xerox
Keith Carter - IBM
Jim Walker - Dazel
Chuck Adams - Tektronix
Stuart Rowley - Kyocera
Peter Zehler - Xerox
David McMaster - TrueSpectra
Jeff Barnett - IBM
Jerry Hadsell - IBM
Steve Adobe - Adobe
Randy Turner - Sharp
Paul Moore - Microsoft
Rob Rhoads - Intel

The following proposed agenda was reviewed and approved:

1) Protocol
2) Security
3) Model
4) Prototyping
5) Directory
6) Internationalization

PROTOCOL

Randy Turner presented his proposal "HTTP 1.1 as a Transport for the Internet
Printing
Protocol which is available as <draft-turner-ipp-trans-develop-00.txt> on the
PWG server
and is also an IETF internet draft.

Issues and comments:
1. Should we suggest a specific URL format as the default for printers
(www.printers.company.com or www.company.com/printers or something else)?
2. Discussion again on "Why HTTP" - no resolution
3. Why would we want to map IPP to different transports? How would different
implementations mapped to different transports ever interoperate?
4. Is HTTP a "stop-gap" solution? If so, when should we start talking about a
longer
term solution?
5. Some of Randy's proposals would require some changes to the Model document.
6. Implementation of Randy's proposal by Sharp preceded the development of the
IPP
Model document.
7. Under Randy's proposal, he recommends that if HTML pages are created for
non-IPP
clients (like an existing browser) that we standardize the type of controls,
etc. are
present on the HTML pages.
8. Discussion on whether an IPP over HTTP implementation should create HTML
pages
(presenting status and capabilities) that turn off caching of that page.
9. Randy's proposal for an IPP server requires only a subset of the full
HTTP/1.1 RFC.

Steve Zilles presented a proposal of an architecture for the IPP protocol.
This was an
interactive session where Steve presented his thoughts in a block diagram
form. As of the
meeting, this proposal has not yet been documented in a paper.

Steve presented an issues list related to protocol:
1. Coded format - content type header
* form data
* IPP unique
2. Transport
* HTTP
* HTTP Subset
* Something else
3. Where encoding operations happen:
* Host
* other
4. One Message or Multiple Messages
* Single POST
* CREATE, SEND
5. Printer status during sending
6. Response to create
* Job data URL
* Query URL
* Modify URL
7. Conformance requirements of >1 of protocol
8. Alignment between Model and Protocol documents
9. Use of accept headers to select
* language
* character set
* encoding
10. No discussion of firewalls
11. What to say in Memphis?

A major discussion occurred focused on having two protocol mappings: one that
is
browser-based (HTTP/HTML) and one that is a richer, peer-to-peer printing
solution to
replace LPD. How do we provide interoperability? Should we define
interoperability?
Are we solving two problems? There was no consensus on this issue, further
discussion
will be on the mailing list. Steve Zilles will report this lack on consensus at
the IETF
meeting in Memphis.

Protocol Work Items and Owners:

Document a transport protocol and provide information as to why that is a good
choice
* HTTP 1.1 (Steve Zilles, Roger Debry)
* HTTP Subset (Randy Turner)
* IPP (Paul Moore)