1 Internet Printing Protocol - July 8-9, 1998
2 Attendees
David Pond Apple
Lee Farrell Canon Information Systems
Ron Bergman Data Products
Shivaun Albright Hewlett Packard
Brian Batchelder Hewlett Packard
Alan Berkema Hewlett Packard
Sandra Matts Hewlett Packard
Ken Oakeson Hewlett Packard
Kris Schoff Hewlett Packard
Harry Lewis IBM
Yuji Sasaki Japan Computer Industry
Stuart Rowley Kyocera
Don Wright(4) Lexmark
Paul Moore Microsoft
Hugo Parra Novell
William Wagner Osicom
Charles Quan Kong Panasonic
Atsushi Uchino Seiko Epson
Randy Turner Sharp
Anthony Fung ST Microelectronics
Tom Hastings Xerox
Carl-Uno Manros Xerox
Xavier Riley Xerox
Rick Yardumian Xerox
Pete Zehler Xerox
3 Administrivia
Don Wright provided details for the next PWG meeting:
· August 17-21
· Toronto Marriott at Eaton Centre
· 525 Bay Street
· Toronto, Ontario, Canada M5G 2L2
· $175CN (about $120 US)
· Deadline is July 24, 1998
Future PWG meeting schedules will have the following structure:
· MIB meetings on Tuesday evenings (if needed)
· PWG Plenary on Wednesday mornings
· IPP meetings on Wednesday afternoon and Thursday morning
· SDP meetings on Thursday afternoon
· UPD meetings on Friday
The PWG meeting calendar for 1999 will be discussed at the next meeting
in Toronto. A first draft of dates and locations will be generated for
review and evaluation.
Carl Uno-Manros opened the IPP meeting. He presented the meeting goals
and proposed agenda topics:
· Discuss Keith Moore's (IETF Application Area Director) comments on IPP
draft documents
· Reactivate us on the registration of Printer MIB document types as
MIME types
· Microsoft's proposal to register IPP extra operations
· Discuss plans for IPP interoperability testing
· Agenda for August IETF Plenary
· Discuss Implementor's Guide activities for IPP
· Discuss a question from the IFAX group: Would the IPP group be
prepared to write a mapping document for IPP to IFAX?
· MIB access over IPP
· IPP Notifications
Carl-Uno noted that it is unlikely that we will be able to address all
the above topics. The first item is the most important (and will
probably occupy most-if not all-of the meeting.)
4 IESG Obstacles on IPP drafts
It was suggested that the PWG group needs to consider their position on
the IPP standards independently of the IETF views and opinions. It was
noted that the PWG members seem to have reached agreement - only the
IETF/IESG has any objections to the latest draft documents. One person
raised the question about whether the group would consider moving
forward with the IPP standard without IETF support. "What does it take
to determine when the IPP v1.0 effort will be completed?"
Someone voiced his frustration with the IETF and strongly suggested that
the PWG group split from IETF control.
[A lively discussion ensued, accompanied by a free flow of ideas and
opinions.]
During the discussion, Randy Turner said that he has received a private
e-mail that suggests there will be another objection to the IPP
documents with regard to security. He was not willing to provide more
details. He believes that there might be a minimal security requirement
that may be raised.
Shivaun Albright pointed out that the IETF has provided useful technical
guidance. She is concerned about the possible negative press that would
result from the PWG splitting from the IETF.
The group is very concerned that the IETF process (and possible
additional objections by the IESG) may delay the process much more.
Carl-Uno believes that the IESG will formally review the documents in
the next three weeks. As a result of that meeting, he believes that they
will provide a complete list of the outstanding problems.
"Why can't we just get to the stage of Proposed (Draft) Standard, and
choose to implement them as written?" (And not wait for total agreement
from the IETF/IESG.)
How about if we just put the word "SHOULD" for including the ipp://
scheme in the specification, and agree not to implement it?
Carl-Uno suggested that people should write to Keith Moore and explain
that they have implemented the current set of documents. Perhaps this
will help to persuade him (and the IESG) to accept the documents as is.
Three alternatives were identified:
· split with the IETF
· wait for the full IETF process
· implement what we have now, and wait for the process to continue -
decide later to change if necessary
An attempt was made to obtain a consensus opinion on which decision the
group wants to follow. Although a formal vote was not taken, it seemed
that several people feel that we should still abide by the IETF/IESG
decisions.
The group agreed that no one should implement the ipp:// scheme until
agreement has been reached within the IETF.
The group then decided to spend the afternoon drafting a response to
Keith Moore. It was suggested that we develop a document that includes
the requested changes from Keith Moore, but also explains why the PWG
members disagree with them.
5 IPP Scheme
Carl-Uno provided a summary of what he understands that Keith Moore
requires for the use of the ipp scheme. Whenever a URL is viewed or used
by a user, it should be "ipp://" to refer to a printer. Also, the ipp
scheme should be used for the MIME content type. However, Carl-Uno
believes that we can use http:// when communicating to the server.
The group reviewed a proposal from Randy Turner that was sent to the
e-mail list on June 16. Various changes were suggested and will be
included in an updated proposal response to Keith Moore.
There were several comments speculating on exactly what Keith Moore
believes. (Unfortunately, he was not present to explain his position.)
An e-mail excerpt from Keith Moore was referenced to help clarify his
position:
There was much concern about the apparent contradiction of requiring
that servers support "a full IPP URL" even though no client
implementation is allowed to use them. There was repeated discussion
about whether this is a reasonable concern. Two individuals strongly
suggested that this requirement should be removed. As a compromise, it
was left as a SHOULD instead of a MUST.
6 IPP Scheme in the Body
Keith Moore also says that any URL in the body content that references
an IPP Printer should use the ipp:// scheme.
7 Security
What happens for translating ipp:// to http:// if security is desired?
How does the new scheme for ipp indicate security? How will a process
determine if an IPP URL should be mapped to http:// or https://? If it
is mandated that ipp:// is used, how can an IPP Printer indicate that it
should be contacted using https://? No clear conclusion was reached for
any of these issues.
Randy said that the IETF would be very happy if IPP included SASL.
Carl-Uno said that if we did, it would further delay things by a few
months.
[More heated exchange of opinions.]
--- "Cooling-off" break ---
Paul Moore summarized an informal conversation that was held during the
break:
Several people feel that a "half-way, pseudo-scheme compromise" (as
currently considered in the modified proposal) will encounter many
problems as we dig deeper into the details. We really need to choose to
use a "pure" ipp:// scheme or a "pure" http:// scheme-not the proposed
"compound" scheme. By convincing the IESG that a compound scheme is not
practical, the group believes that the IESG will agree to using http://
rather than forcing us to start all over and develop a completely new
scheme.
The group again agreed that we should continue to develop a document
that addresses the requested changes from Keith Moore, but also explains
why the PWG members believe it will not work. The group believes that
this approach will be useful to prove that we did our "due diligence" in
attempting to meet the suggestions from Keith Moore. However, after
serious consideration, the group has found that the suggestions do not
produce a viable solution for achieving the protocol.
The group generated a list of several problems with the proposal
(included at the end of the modified proposal-see below.)
8 Proposal Update - continued
The next day, the group participated in a review of some modifications
to the proposal that Randy had made the night before.
There was much debate about Randy's proposal for including a security
parameter in a URL scheme. Several attendees were concerned that the
IESG would not accept a parameterized URL scheme. No one was aware of
any precedent for this concept, and a few people suggested that defining
such a parameterized scheme should be done outside the IPP WG.
Additional modifications to the proposal resulted in the following
document:
IPP Working Group Analysis of Proposed IPP URL Scheme
----------------------------------------------------------------------
Introduction
The IETF Applications Area Director has proposed that the IPP working
group consider creating a new URL scheme, "ipp:", to reference IPP
objects, as defined in the IPP Model Document. The IPP working group
has created a usage model of how a potential IPP URL would be used,
if implemented and deployed. This usage model is included in this
document analysis, for completeness.
A subsequent analysis of the usage model for this new scheme has
exposed some critical issues and concerns that the IPP working group
has with the proposed "ipp:" scheme. Considering the impact of these
issues, the working group feels that the integration of a new URL
scheme into the IPP model and protocol specifications is not feasible
at this time.
Usage Model for "ipp" Scheme
-----------------------------------------------------------------------
In its current definition, IPP uses HTTP 1.1 as a transport protocol,
and
hence uses the existing "http:" URL scheme, in which URL path names and
MIME types are used to multiplex and demultiplex IPP from the HTTP
protocol data stream.
The conventional model for the introduction of a new protocol scheme
assumes that the URL scheme maps directly to an application protocol,
network transport protocol and default transport "port number".
Typically, this transport protocol includes a
multiplexing/demultiplexing
capability based on the idea of a port number (e.g., TCP, UDP).
The working group considered using the "ipp:" URL scheme using the
conventional model, but the current HTTP infrastructure
(existing HTTP 1.1 servers and proxies) does not understand "ipp:" URLs,
and would not reliably transport HTTP messages containing headers that
reference "ipp:" URLs.
We finally considered a "compound" URL scheme, wherein a translation
from
"ipp:" to "http:" URL schemes is performed.
The syntax for the new IPP scheme is identical to the existing
"http" scheme except for the scheme name itself. The similarity is
maintained to ease the IPP-to-HTTP translation burden:
ipp://host[:port]/<IPP-specific-abs-path>
Associated with this new IPP scheme is an IANA-assigned TCP port
number, 631, which is the default port number used by clients to
contact IPP servers that are represented by IPP URLs.
The IPP scheme implies all of the same protocol semantics as that of
the HTTP scheme, except that, by default, the port number used by
clients
to connect to the server is port 631. The semantics for clients
configured for proxy access is different as described below.
The implementation impact of using the new scheme on the existing
specifications is divided into two key areas: HTTP headers and the
application/ipp MIME body part.
------------------------------------------------------
HTTP Header Usage
------------------------------------------------------
When an IPP client obtains an IPP URL, the interpretation (translation)
of this URL by the client can take one of two forms, depending upon
whether
the client is configured to use an HTTP 1.1 proxy server.
IPP Client Configured with no proxy server
------------------------------------------------------
When an IPP client (no proxy configured) obtains an "ipp:" URL such
as "ipp://myhost.com/myprinter/myqueue", it MUST open an TCP connection
to
port 631 on myhost.com, with the following example headers:
POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
IPP Client Configured for Proxy Service
------------------------------------------------------
When an IPP client that uses a proxy named "myproxy.com" obtains the URL
"ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection to
myproxy.com with the following example headers:
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:8080
Content-type: application/ipp
Transfer-Encoding: chunked
...
Existing proxies will not understand IPP URLs, so the RequestURI MUST
use the HTTP form of the URL.
After proxy processing, the proxy would connect to the IPP origin server
with
headers that are the same as the "no-proxy" example above.
IPP/HTTP Server Implications
-------------------------------------------------------------------
Existing HTTP 1.1 clients (and IPP clients) will only contact IPP origin
servers using a requestURI specified in #1 below. However, RFC 2068
states
that HTTP 1.1 servers MUST accept "full" URLs as well, so IPP servers
MUST also be able to accept a requestURI as specified in #2 as well.
Also,
IPP servers SHOULD be able to accept a full requestURI as specified in
#3
below. Servers MUST interpret all of the forms below as equivalent.
1. A "abs_path" URL (e.g., /myprinter/myqueue)
2. A full HTTP URL (e.g
http://myhost.com:631/myprinter/myqueue)
3. A full IPP URL (e.g., ipp://myhost.com/myprinter/myqueue)
NOTE: Example #3 is included to support the possible future deployment
of
IPP services that utilize full IPP requestURIs. Currently, this
specification does not allow clients to generate full IPP requestURIs.
In all forms of "ipp" URL translation, if an explicit port number is
specified
then this port number MUST be used by the clients and proxies to
initiate
connections to IPP/HTTP origin servers.
-------------------------------------------------
application/ipp MIME body
-------------------------------------------------
Printer and job URI attributes in the protocol MUST utilize the "ipp"
scheme. The application/ipp body part contains the following URI
components that are affected:
job attributes -
job-uri
job-printer-uri
printer attributes -
printer-uri-supported
operation attributes -
job-uri
printer-uri
Other URI attributes in the protocol can contain any number of different
URL schemes, e.g., document-uri, printer-more-info, and are not
affected by the "ipp" scheme.
-------------------------------------------------------------------
Summary Conclusions
-------------------------------------------------------------------
The IPP working group has serious concerns regarding integrating a new
"ipp:" URL into our specifications. The following issues have been
raised with regards to usage of the "ipp:" scheme.
1. There is currently no defined way for a single "ipp:" URL to
indicate whether or not a particular IPP server offers "secure"
connections. Throughout the IPP model document, numerous
assumptions are made with regards to our usage of the "http:" URL
to reference IPP objects, chief among these assumptions is that
IPP clients treat URL syntax beyond the "host" part of an HTTP URL
as opaque.
The IPP working group feels that any specification for security
parameters within URL syntax should be a "standard" solution and not
specifically a "one-off" or one-time only solution for IPP.
The effort required to put together a group or effort to accomplish
this is out-of-scope for our current charter.
2. There is no straightforward way to configure HTTP client proxy
capability for "proxying" IPP. Currently, there are specific proxy
configuration options for HTTP clients, such as FTP, GOPHER, HTTP,
WAIS, etc. There is no option for proxying "ipp:" URLs and this
deficiency could lead to confusion for the end user. Also, to
correctly
configure a proxy service for IPP, the user will have to "know"
that IPP actually uses HTTP, and that for IPP proxy service the user
must configure an HTTP proxy.
3. Similar to the end-user configuration problem in #2 above, there is
currently no proxy configuration option for IPP proxy in existing
proxy server software. IPP will be a "special case" wherein the
administrator will have to know the special relationship between
IPP URLs and HTTP URLs.
4. Future use of the "ipp" scheme is compromised by using the new "ipp"
scheme in the translated form implied by the proposed "ipp:" scheme.
The IPP working group would like to reserve use of the "ipp" scheme
for a pure IPP client/server protocol implementation in the future
(one that does not require utilization of an existing HTTP
infrastructure). In this environment, it seems appropriate to attach
the "ipp" URL to this future protocol, rather than the initial IPP
protocol that is just carried in a MIME type within HTTP.
For example, in a future implementation of an IPP scheme that does
not utilize HTTP, existing IPP clients would still attempt to
translate the "ipp:" scheme into an "http:" scheme, and would do so
incorrectly, since the future "ipp:" scheme protocol might not use
HTTP as a transport.
5. The proposal introduces "compound" spoofing by using an "ipp:" scheme
and transparently translating it to an "http:" scheme An initial
concern was the fact that there was no way to tell that IPP was
actually being used by looking at an HTTP URL. However, publishing
and using only IPP URLs to the user and administrator community might
hide the fact that IPP is actually using HTTP.
6. Compound schemes is a new idea and not well understood in its'
ramifications. In the current IANA registry for URL schemes, there
are no examples that indicate that scheme "translation" to another
scheme is required.
7. All applications that include URI/URL recognition features will have
to be updated to include support for the new "ipp:" URL.
8. Existing network infrastructure tools and utilities would need to
be modified in order to understand the "special" relationship
between IPP and HTTP URLs.
The working group considers IPP printing an "HTTP application", and
therefore the usage of an "ipp:" URL scheme must maintain a special
relationship with "http:" URLs. The definition of such a "compound"
URL scheme, wherein an "ipp:" scheme is layered or translated to an
"http:" scheme, is somewhat unusual, and the impact of such a definition
on the protocol design and deployment is not generally well understood.
This analysis document has identified a partial list of issues regarding
the integration of the new "ipp:" scheme. It is anticipated that other
unforeseen issues exist, since this technique has not been prototyped.
If the usage model described herein were adopted, these issues raised in
this analysis pose a significant negative impact on the implementation
and deployment of current IPP specifications, as well as potential
interoperability with future revisions of the protocol.
This document will be forwarded to the IESG.
9 Interoperability Testing
Pete Zehler announced that 13 companies (of 35 companies contacted) have
said they are willing to make an announcement about their current status
with regard IPP development. The other companies either have not
responded, or prefer to keep their status private.
Connectivity issues and bugs in implementations seem to be the major
activity being addressed in the pair-wise testing that is currently
occurring. More testing has occurred, but the participants continue to
guard their activity results.
Pete believes that an interoperability "bake-off" might be achievable
some time in September, or later in the year. A major concern is having
sufficient test tools to support such an effort.
It was suggested that a poll should be taken to see which vendors are
ready (or would be willing) to participate in an interoperability test
within the next several weeks.
Xerox, IBM, Microsoft, and Lexmark all said that they are willing and
able to participate in a bake-off on September 15.
Pete will send out a list of company status and contact points. He will
also send out a request for additional participants for a September 15
bake-off. All implementations will be based on the June 30 specification
documents.
It was estimated that the bake-off would last three days.
10 IETF Plenary Meeting Agenda
Carl-Uno asked what should be planned for the IPP session during the
next IETF Plenary in August. After a short discussion, the following
topics were suggested:
· Status review
· Implementation progress
· Discussion of open issues based on IESG feedback
11 Implementers Guide
Several participants agreed that we should document clarifications and
"lessons learned" from IPP implementation efforts. Carl-Uno volunteered
to collect material for this document. He also said that he would update
the FAQ document.
12 A Mapping Document for IPP to IFAX
Carl-Uno asked if anyone would be willing to write a mapping document
from IPP to IFAX. One suggestion was that Larry Masinter (who made the
request) should provide more information on what he envisions. Harry
Lewis said that he would be interested in talking with Larry about this.
IPP Meeting adjourned
---
My cincere thanks to Lee Farrell for taking the notes.
Please note that later discussion with Keith Moore seems to make it
quite clear that there is an ipp:// scheme in IPP's future.
Further feedback expected from the IESG after their July 30 meeting.
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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 at cp10.es.xerox.com