Below are the more detailed minutes from the IPP WG Meeting in =
Minneapolis.
Many thanks to Lee Farrell for taking the notes and getting them ready =
for=20
distribution so quickly.
Carl-Uno
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IPP WG Minutes - March 17, 1999
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Carl-Uno Manros led the meeting for the Internet Printing Protocol =
(IPP) WG
session. Around 30 people attended. Notes taken by Lee Farrell.
Agenda
=B7 IPP Status - Where do we stand?
=B7 Highlights from the IPP bake-off
=B7 Presentation of IPP 1.1 documents
=B7 Highlight differences between 1.0 and 1.1
=B7 Open discussion
IPP Status
=B7 The five draft documents that constitute IPP/1.0 have been accepted =
by the
IESG as Experimental. These five documents are currently in the RFC =
Editor's
queue for publication
=B7 An IPP/1.0 Implementer's Guide document is currently out for IPP WG =
Last
Call
=B7 Two new drafts have been produced for IPP/1.1. They are currently =
out for
IPP WG Last Call
Some objections have been raised on the mail list about finalizing =
IPP/1.1
"too quickly" before reasonable experience is gained on IPP/1.0. There =
is
especially some concern with regard to over 20 issues that came up at =
the
2nd bake-off. Tension exists between delaying too long before the first
standards track draft is issued and waiting for "sufficient stability" =
in
experience with 1.0 version implementations before issuing a second
specification.
Carl-Uno showed slides on the bake-off event. He explained the
infrastructure set-up and services.
Highlights from the IPP bake-off
=B7 24 vendors (Carl-Uno provided list)
=B7 11 IPP clients
=B7 27 IPP printers
=B7 297 possible combinations=20
=B7 296 "basic print" feature successful after 3 days (one hold-out due =
to ROM
implementation-couldn't modify code)
It was noted that "new faces" (i.e. never attended an IPP meeting) =
brought
successful implementations. This suggests that the IPP/1.0 =
specification is
clear enough for consistent interpretation.
Genoa is developing an IPP test suite that will be made available to =
the
open market.
Q: How many vendors demonstrated the ability to handle multiple =
concurrent
sessions?=20
A: It wasn't really one of the tests, but there was a wide spectrum of
capability present-including a OS/390 mainframe machine that could =
handle 20
simultaneous HTTP/IPP connections.
Carl-Uno brought with him and showed a palm-sized IPP Print Server =
device
implemented by i-data. It has 4 MB memory, and supports TCP/IP, HTTP, =
SNMP,
SMTP, and SSL3, with a web server, plus four print protocols, including =
IPP.
Presentation of IPP 1.1 documents
=B7 IPP Protocol: Model and Semantics - draft-ietf-ipp-model-v11-00.txt
=B7 IPP Protocol: Encoding and Transport - =
draft-ietf-ipp-protocol-v11-00.txt
Important Differences between IPPv1.0 and v1.1
=B7 Six new optional Operations
=B7 Introduction of the ipp:// scheme
=B7 TLS replaces SSL3 ("should" support TLS)
New Operations (all optional)
=B7 Printer Operations
* Pause-Printer
* Resume-Printer
* Purge-Jobs
=B7 Job Operations
* Hold-Job
* Release-Job
* Restart-Job
Carl-Uno provided background comments on the group's reluctance to =
adopt the
IESG recommendation to implement ipp:// scheme. However, he points out =
that
several people have shown that the scheme is relatively simple to =
implement.
It was noted that http:// is used on the wire. The Client translates =
before
sending. Any URLs contained in the MIME message body are maintained as
ipp://.
ipp:// scheme:
=B7 Synonym for http://
=B7 Has its own default port--#631
=B7 Easy to map from/to http:// scheme
=B7 If client uses http://, server responds with http://
=B7 If client uses ipp://, server responds with ipp://
Use of TLS vs. SSL3
=B7 SSL3 uses special scheme https:// and special port #443
=B7 TLS uses ipp:// scheme and same port as IPP-#631
=B7 For SSL3, the IPP client has to start up with https:// and later =
switch to
http://
=B7 For TLS, the IPP client starts up with http:// using the Upgrade =
header
Carl-Uno noted that he has heard rumors about "one little problem" with =
the
Upgrade header, but the details were not clear. There was speculation =
that
there might be a need for a registry of tokens and their meanings-to =
avoid
collisions.
He also noted that there is not a lot of TLS code "lying around" for =
general
use. He requested if anyone knows about SDK for TLS in Java-please =
notify
him; the IPP WG is interested.
There was some discussion about handling both TLS and SSL3. There was =
some
confusion about the correct interpretation regarding support of IPP/1.0 =
(and
SSL3) as part of IPP/1.1. Carl-Uno suggested that if people have any
suggestions for existing text on this issue, please send him comments. =
The
Last Call period on the current document set will be extended.
Discussion about IPP-to-IFax BOF activity (now "TCN Docs"). One person
reported that it is still not clear from the Area Director whether IPP =
is
the accepted mechanism for the goals of this group. He explained that =
"due
diligence" must be performed on clarifying the problem statement. There =
is a
perception that the current approach might be "a solution looking for a
problem."
Larry Masinter proposed that it's a small amount of work to merge both
document sets (IPP/1.0 and IPP/1.1) into one. He suggests that we could =
pull
the current experimental RFC documents from the Editor's queue, and =
include
in the IPP/1.1 documents an informational description of IPP/1.0.=20
Larry pointed out that the preface to Experimental RFCs includes =
warnings
that they are not standards-and should not be implemented.
Carl-Uno expressed his belief that many of the vendors that attended =
the
Bake-off would be upset about "pulling the IPP/1.0 RFCs." He pointed =
out
that there was strong desire to establish a document set to clearly =
define
the IPP/1.0 version.
A popular compromise was suggested: do both. Include the "merge" of =
IPP/1.0
description within the IPP/1.1 document set-and obsolete the IPP/10
Experimental RFCs once the combined IPP/10 and 1.1 version is =
published. A
benefit of this approach is that all relevant information would be =
available
in a single document set-rather than having two document sets that are
essentially the same.
Strong majority agreed that this was a good compromise approach. No one
voiced any objections.
Larry and John Wenn volunteered to propose text modifications to =
achieve the
merge. The proposed text will be issued for review by the IPP mailing =
list.
Issues to be addressed:
=B7 How difficult is the actual modification of the documents?
=B7 Is IPP/1.0 really a true subset of IPP/1.1?
=B7 Can we (continue to) avoid the requirement that 1.1 Clients need to
support 1.0 Servers?
=B7 "How to be compatible with existing 'pre-standard' (i.e. IPP/1.0)
implementations of IPP?"
Larry will analyze the effort to merge, and will issue a =
statement/proposal
to the reflector as appropriate.
Meeting adjourned.
Shortly after the meeting, the chair extended the Last Call period for =
the
IPP/1.1 documents and the IPP Implementer's Guide until April 30, 1999.
-----
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@cp10.es.xerox.com=20